You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Ali Demir <de...@yahoo.com> on 2005/02/24 07:08:51 UTC
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout()
support.
Thank you!
How does the internals work? Does the cancelled query release all the locks
it might have been holding? Does it only work for this kind of select? What
if it were waiting for another insert/update transaction? Would it still be
able to cancel the select and return?
Regards,
Ali
At 09:28 PM 2/23/2005, you wrote:
> [ http://issues.apache.org/jira/browse/DERBY-31?page=history ]
>
>Shreyas Kaushik updated DERBY-31:
>---------------------------------
>
> Attachment: Derby-31.patch
>
>This is the patch for implementing setQueryTimeout()
>in EmbedStatement.java . I clsoe the activation for the statement when
>the query times out so that the query stops executing. I tested this by
>inserting data into a table continuosly for about 12 hours and then doing
>a select * on it by setting the time out to 1 sec. It worked fine by
>cancelling the statement execution when the timeout happened.
>
> > Statement.setQueryTimeout() support.
> > ------------------------------------
> >
> > Key: DERBY-31
> > URL: http://issues.apache.org/jira/browse/DERBY-31
> > Project: Derby
> > Type: New Feature
> > Components: JDBC
> > Environment: ALL
> > Reporter: Ali Demir
> > Attachments: Derby-31.patch, QueryTimer.java
> >
> > Calling Statement.setQueryTimeout() throws exception saying that
> function is not supported. This is an important JDBC feature and is
> limiting our options to use Derby with our JDBC code. Implementing this
> JDBC function would make Derby much easier to adopt.
>
>--
>This message is automatically generated by JIRA.
>-
>If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
>-
>If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by RPost <rp...@pacbell.net>.
>>Ali Demir wrote:
>>Does the cancelled query release all the locks it might have been holding
>"Shreyas Kaushik" wrote:
> closing the activation all the tree of ResultSet and other resources
should get released.
Have you confirmed that the closing of the activation performs a rollback?
The SQL standard I have says
"An SQL-transactin is terminated by a <commit statement> or a <rollback
statement>".
Are latches being released? It was my understanding from Mike's description
of log/store that even queries obtain latches, but not locks, on database
pages. If so, then I would think that these latches need to be released and
that you need to perform any testing necessary to ensure that they are
getting released. If latches are not released it will affect other
transactions.
What about user-defined functions? If a query can contain references to
user-defined functions and those functions can be written so as to modify
the database as a side-effect then a query (as opposed to an
insert/update/delete) could also obtain latches and locks that need to be
released.
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Satheesh Bandaram wrote:
> I haven't reviewed the patch fully, but some comments I see are:
>
> 2. DMLs statements could also use timeouts... especially the searched
> ones. I think we should handle executeUpdate() methods too.
> 4. Shouldn't we handle the cases of PreparedStatement and
> CallableStatement as well?
Yes to both 2) and 4) but an initial contribution could just handle
Statement.executeQuery() as Shreyas has. The hard part to this is first
defining what cancel actually does, and then implementing it. Expanding
that to updates, all implementations of Statement and then query timeout
would be the logical next steps.
Dan.
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
I have implemented this for a SQL Query timeout. I thought this is not
applicable to insert and update timeouts ( I donno
if there is something like that and how do we set that ). This is for
*queries only* .
What my patch addresses is the closing of the activation for that
statement when there is a timeout. It is the activation that
holds the key to all the stuff below it( includes the ResultSets) so by
closing the activation all the tree of ResultSet and
other resources should get released. I did a memory profiling after
doing this patch and it did not detect any memory leaks.
thanks
Shreyas
Ali Demir wrote:
> Thank you!
>
> How does the internals work? Does the cancelled query release all the
> locks it might have been holding? Does it only work for this kind of
> select? What if it were waiting for another insert/update transaction?
> Would it still be able to cancel the select and return?
>
> Regards,
> Ali
>
>
> At 09:28 PM 2/23/2005, you wrote:
>
>> [ http://issues.apache.org/jira/browse/DERBY-31?page=history ]
>>
>> Shreyas Kaushik updated DERBY-31:
>> ---------------------------------
>>
>> Attachment: Derby-31.patch
>>
>> This is the patch for implementing setQueryTimeout() in
>> EmbedStatement.java . I clsoe the activation for the statement when
>> the query times out so that the query stops executing. I tested this
>> by inserting data into a table continuosly for about 12 hours and
>> then doing a select * on it by setting the time out to 1 sec. It
>> worked fine by cancelling the statement execution when the timeout
>> happened.
>>
>> > Statement.setQueryTimeout() support.
>> > ------------------------------------
>> >
>> > Key: DERBY-31
>> > URL: http://issues.apache.org/jira/browse/DERBY-31
>> > Project: Derby
>> > Type: New Feature
>> > Components: JDBC
>> > Environment: ALL
>> > Reporter: Ali Demir
>> > Attachments: Derby-31.patch, QueryTimer.java
>> >
>> > Calling Statement.setQueryTimeout() throws exception saying that
>> function is not supported. This is an important JDBC feature and is
>> limiting our options to use Derby with our JDBC code. Implementing
>> this JDBC function would make Derby much easier to adopt.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> If you want more information on JIRA, or have a bug to report see:
>> http://www.atlassian.com/software/jira
>
>
>