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 de...@db.apache.org on 2004/10/04 20:55:32 UTC
[jira] Created: (DERBY-31) Statement.setQueryTimeout() support.
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DERBY-31
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DERBY-31
Summary: Statement.setQueryTimeout() support.
Type: Improvement
Status: Unassigned
Priority: Major
Project: Derby
Assignee:
Reporter: Ali Demir
Created: Mon, 4 Oct 2004 11:54 AM
Updated: Mon, 4 Oct 2004 11:54 AM
Environment: ALL
Description:
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.
---------------------------------------------------------------------
JIRA INFORMATION:
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 Daniel John Debrunner <dj...@debrunners.com>.
Deepa Remesh wrote:
> Hi,
>
> I am Deepa Remesh and I work for IBM. I am just starting to work on
> Derby and was trying to apply the patch for DERBY-31. I noticed that
> the file QueryTimer.java is not in the patch file but is attached
> separately. I had to manually add it to the Eclipse project before
> compiling. It would be good if this file is added to the patch.
I think the patch by Oyvind does not include QueryTimer.java. That is
part of an older initial attempt at providing this feature. I was
confused as well when I applied the previous version by Oyvind last weekend.
Dan.
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Kathey Marsden wrote:
>Oyvind.Bakksjo@sun.com wrote:
>
>
>
>>The "QueryTimer.java" and "Derby-31.patch" files were submitted by
>>someone else on February 24.
>>
>>
>
>Shreyas, would you mind deleting the old patch to avoid confusion.
>
Yes will do this, I know I have a big back log of things to-do here :-)
> Also
>I was thinking you might be interested in reviewing Oyvind's patch since
>you have shown interest in this issue in the past.
>
I reviewed his patch and most of the comments I had were covered by
Dan's comments. If there are any new things I will definitely post it.
~ Shreyas
>Perhaps Oyvind would
>be willing to review your patch for DERBY-156 as well.
>
>Kathey
>
>
>
>
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Oy...@Sun.COM.
Kathey Marsden wrote:
> Oyvind.Bakksjo@sun.com wrote:
>
> Shreyas, would you mind deleting the old patch to avoid confusion. Also
> I was thinking you might be interested in reviewing Oyvind's patch since
> you have shown interest in this issue in the past. Perhaps Oyvind would
> be willing to review your patch for DERBY-156 as well.
Sure, I'll review it.
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Kathey Marsden <km...@sbcglobal.net>.
Oyvind.Bakksjo@sun.com wrote:
>
> The "QueryTimer.java" and "Derby-31.patch" files were submitted by
> someone else on February 24.
Shreyas, would you mind deleting the old patch to avoid confusion. Also
I was thinking you might be interested in reviewing Oyvind's patch since
you have shown interest in this issue in the past. Perhaps Oyvind would
be willing to review your patch for DERBY-156 as well.
Kathey
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Oy...@sun.com.
Hi Deepa,
please see comments inline:
Deepa Remesh wrote:
> Hi,
>
> I am Deepa Remesh and I work for IBM. I am just starting to work on
> Derby and was trying to apply the patch for DERBY-31. I noticed that
> the file QueryTimer.java is not in the patch file but is attached
> separately. I had to manually add it to the Eclipse project before
> compiling. It would be good if this file is added to the patch.
If you look at the dates and origin of the attachments to DERBY-31, you
will notice the following:
The "QueryTimer.java" and "Derby-31.patch" files were submitted by
someone else on February 24. Unfortunately, this patch is too simple and
does not fix the issue.
The patch I submitted on June 15 is in DERBY-31.svn.diff; my attachments
are the three files listed further below in this email message.
QueryTimer.java is not a part of this patch.
>
> Thanks,
> Deepa
>
> On 6/15/05, Oyvind Bakksjo (JIRA) <de...@db.apache.org> wrote:
>
>> [ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
>>
>>Oyvind Bakksjo updated DERBY-31:
>>--------------------------------
>>
>> Attachment: DERBY-31.svn.status
>> DERBY-31.svn.diff
>> derbyall_report.txt
>>
>>Attached patch addresses the following issues:
[...]
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Deepa Remesh <dr...@gmail.com>.
Hi,
I am Deepa Remesh and I work for IBM. I am just starting to work on
Derby and was trying to apply the patch for DERBY-31. I noticed that
the file QueryTimer.java is not in the patch file but is attached
separately. I had to manually add it to the Eclipse project before
compiling. It would be good if this file is added to the patch.
Thanks,
Deepa
On 6/15/05, Oyvind Bakksjo (JIRA) <de...@db.apache.org> wrote:
> [ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
>
> Oyvind Bakksjo updated DERBY-31:
> --------------------------------
>
> Attachment: DERBY-31.svn.status
> DERBY-31.svn.diff
> derbyall_report.txt
>
> Attached patch addresses the following issues:
> * Throw exception on negative input to setQueryTimeout()
> * Test case for the above
> * Use milliseconds instead of seconds in the PreparedStatement interface and GenericPreparedStatement class
> * Exclude SetQueryTimeoutTest from DerbyNet and DerbyNetClient, since these environments don't yet support the new functionality (will create a fix for the DerbyClient driver later
>
> Derbyall has been run with two failures, report attached.
> StmtCloseFunTest - hard to tell if it's related to my changes, very little output from the test about what exactly failed.
> miscerrors - doesn't seem related
>
>
> > 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
> > Assignee: Oyvind Bakksjo
> > Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, Derby-31.patch, QueryTimer.java, derbyall_report.txt
> >
> > 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
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Oyvind Bakksjo (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12357683 ]
Oyvind Bakksjo commented on DERBY-31:
-------------------------------------
Updated documentation which stated setQueryTimeout was not implemented.
Sending src/ref/rrefjdbc40794.dita
Transmitting file data .
Committed revision 344345.
> 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
> Assignee: Oyvind Bakksjo
> Fix For: 10.2.0.0
> Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, derbyall_report.txt
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Oyvind Bakksjo (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
Oyvind Bakksjo reassigned DERBY-31:
-----------------------------------
Assign To: Oyvind Bakksjo
> 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
> Assignee: Oyvind Bakksjo
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Oyvind.Bakksjo@Sun.COM wrote:
> Daniel John Debrunner wrote:
>> Oyvind, do you want me to commit your current patch (I've made the
>> copyright date changes, and performed the svn adds and propsets) and
>> then you could fix this problem quickly?
>
>
> I wouldn't want to check in anything that is known to cause tests to
> fail, even temporarily.
>
> The fix is very simple; adding a call to checkStatus() at the very top
> of EmbedStatement.setQueryTimeout() fixes the problem. If you want me
> to, I can submit a new patch, but I think the quickest approach would be
> if you just inserted the 'checkStatus()' call in your own sandbox.
I'll do this & re-run tests.
Dan.
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Oy...@Sun.COM.
Daniel John Debrunner wrote:
> Daniel John Debrunner wrote:
>
>
>>Daniel John Debrunner wrote:
>>
>>
>>
>>I had to re-run the tests because the patch messed up on one file, but
>>now StmtCloseFunTest fails for me with this patch.
>>
>>*** Start: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:08:57 ***
>>2a3
>>
>>
>>>Statement Test failed (10)
>>
>>4a6
>>
>>
>>>Prepared Statement Test failed
>>
>>7a10
>>
>>
>>>Callable Statement Test failed
>>
>>Test Failed.
>>*** End: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:09:05 ***
>>
>>I'll look into it, but is anyone else seeing this failure?
>
>
>
> This is because the setQueryTimeout used to throw a not implemented
> exception, but now succeeds. But in this case the statement is closed so
> according to the JDBC spec, all such methods should throw an exception.
>
> Oyvind, do you want me to commit your current patch (I've made the
> copyright date changes, and performed the svn adds and propsets) and
> then you could fix this problem quickly?
I wouldn't want to check in anything that is known to cause tests to
fail, even temporarily.
The fix is very simple; adding a call to checkStatus() at the very top
of EmbedStatement.setQueryTimeout() fixes the problem. If you want me
to, I can submit a new patch, but I think the quickest approach would be
if you just inserted the 'checkStatus()' call in your own sandbox.
Sorry for not catching this one myself; there was a lot of complaining
about broken builds and derbyall not running cleanly at the time, and I
guess I was just a bit lazy... Won't *ever* happen again. ;o)
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Daniel John Debrunner wrote:
> Daniel John Debrunner wrote:
>
>
>>Oyvind.Bakksjo@Sun.COM wrote:
>>
>>[on comments about re-use of TimerTasks]
>> write a comment about this in the code in a subsequent
>>
>>
>>>patch (for instance when implementing Statement.cancel), unless anybody
>>>wants me to address this now and submit a new patch.
>>
>>
>>I think delaying the comment is fine.
>>
>>I'm planning to commit this change before the end of this week, assuming
>>all the tests run for me.
>
>
> I had to re-run the tests because the patch messed up on one file, but
> now StmtCloseFunTest fails for me with this patch.
>
> *** Start: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:08:57 ***
> 2a3
>
>>Statement Test failed (10)
>
> 4a6
>
>>Prepared Statement Test failed
>
> 7a10
>
>>Callable Statement Test failed
>
> Test Failed.
> *** End: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:09:05 ***
>
> I'll look into it, but is anyone else seeing this failure?
This is because the setQueryTimeout used to throw a not implemented
exception, but now succeeds. But in this case the statement is closed so
according to the JDBC spec, all such methods should throw an exception.
Oyvind, do you want me to commit your current patch (I've made the
copyright date changes, and performed the svn adds and propsets) and
then you could fix this problem quickly?
I see now you did say
[comment from Derby-31]
Derbyall has been run with two failures, report attached.
StmtCloseFunTest - hard to tell if it's related to my changes, very
little output from the test about what exactly failed.
The way to investigate this would be to first look at the diff and see
if the output helps in any way. In this case there was a new line of
Statement Test failed (10)
Looking at the test source code, you can then see that the 10 is really
a test case number, this was determined by either searching for 10 in
the source or searching for the complete text 'Statement Test failed (10)'.
Looking at the code for that test case, you can see that the output is
printed if setQueryTimeout succeeds. The fact that this is a call to
setQueryTimeout means that it is related to your change.
Other ways to see which area of a java test is causing the problem is to
see if there is a stack trace being printed. If so the line number
within the test case is a good starting point. Often the stack trace
will be in the '.tmp' output file, but not the '.out' file. Thus it is a
good practice in test code to always print the stack trace for any
unexpected exception.
Dan.
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Daniel John Debrunner wrote:
> Oyvind.Bakksjo@Sun.COM wrote:
>
> [on comments about re-use of TimerTasks]
> write a comment about this in the code in a subsequent
>
>>patch (for instance when implementing Statement.cancel), unless anybody
>>wants me to address this now and submit a new patch.
>
>
> I think delaying the comment is fine.
>
> I'm planning to commit this change before the end of this week, assuming
> all the tests run for me.
I had to re-run the tests because the patch messed up on one file, but
now StmtCloseFunTest fails for me with this patch.
*** Start: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:08:57 ***
2a3
> Statement Test failed (10)
4a6
> Prepared Statement Test failed
7a10
> Callable Statement Test failed
Test Failed.
*** End: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:09:05 ***
I'll look into it, but is anyone else seeing this failure?
Dan.
Footprint - Was Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout()
support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David Van Couvering wrote:
> Hi, Dan. Can you clarify me the motivation behind keeping the footprint
> down? Are we targeting PDAs? What kind of platforms are you
> envisioning for Derby that require a minimal footprint? I agree that in
> general smaller is better, but for instance is smaller a priority over
> readability/maintainability (for example, building an architecture with
> fewer classes doing more things rather than more classes with
> well-defined responsibilities)? Is it a priority over performance? Is
> it a priority over more advanced features such as replication, XML
> support, additional SQL features, etc.? What's the order of precedence
> for these types of key qualities of Derby, in your view?
I think it's a balance of qualities, footprint, features, ease of use,
performance. Footprint and features are very concrete things people
measure databases with, thus if Derby has a footprint that is ten times
larger than other comparable technologies it will be rejected at an
early stage. For features I think there are core features that need to
be part of the technology and others that should be optional for people
to choose. Thus, I believe, XML support will be an essential part of
every database thus building in it is fine, replication on the other
hand should be optional so that people aren't forced to pay the overhead.
I do believe there is a good fit for Derby on embedded servers, set-top
boxes, cash registers, gaming machines where footprint is a concern.
Over time with Cloudscape we saw (and continue to see) people want all
the SQL features, a JDBC engine that just does basic operations doesn't
interest folks. People would love Cloudscape's functionality in 100k.
It's also, to me, an interesting challenge, provide the value of the
functionality within a small footprint as possible, without sacrificing
performance, quality and ease of use.
And finally, this is open source, Apache can provide basic packaging of
the software, anyone else can package it as they want. If someone
believes they can provide value by shipping a J2ME specific Derby
engine, that's great, or look at Gluecode, their value was a complete
J2EE stack with Derby. The Derby project has to provide the core
technology and some reasonable packaging, encourage others to build
projects or products based upon Derby.
Dan.
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by David Van Couvering <Da...@Sun.COM>.
Hi, Dan. Can you clarify me the motivation behind keeping the footprint
down? Are we targeting PDAs? What kind of platforms are you
envisioning for Derby that require a minimal footprint? I agree that in
general smaller is better, but for instance is smaller a priority over
readability/maintainability (for example, building an architecture with
fewer classes doing more things rather than more classes with
well-defined responsibilities)? Is it a priority over performance? Is
it a priority over more advanced features such as replication, XML
support, additional SQL features, etc.? What's the order of precedence
for these types of key qualities of Derby, in your view?
Thanks,
David
Daniel John Debrunner wrote:
> Oyvind.Bakksjo@Sun.COM wrote:
>
>>Daniel John Debrunner wrote:
>
>
>>>rather than a new error XJ074.S, the existing generic error XJ081.S
>>>(added by Shreyas) could have been used.
>>
>>
>>OK. Considering e.g. these existing codes (see below), it was not clear
>>to me what was the preferred way - adding a separate code or using a
>>generic one.
>>
>> String INVALID_FETCH_SIZE = "XJ062.S";
>> String INVALID_MAX_ROWS_VALUE = "XJ063.S";
>> String INVALID_FETCH_DIRECTION = "XJ064.S";
>> String INVALID_ST_FETCH_SIZE = "XJ065.S";
>> String INVALID_MAXFIELD_SIZE = "XJ066.S";
>
>
>
> I think the discussion was that when Shreyas added a new similar message
> and ita was resolved that adding a generic message and that existing
> code could converge to its use over time.
>
> I can add a Jira entry for this. My "itch" is keeping the footprint down
> in whatever way possible.
>
> Dan.
>
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Oyvind.Bakksjo@Sun.COM wrote:
> Daniel John Debrunner wrote:
>> rather than a new error XJ074.S, the existing generic error XJ081.S
>> (added by Shreyas) could have been used.
>
>
> OK. Considering e.g. these existing codes (see below), it was not clear
> to me what was the preferred way - adding a separate code or using a
> generic one.
>
> String INVALID_FETCH_SIZE = "XJ062.S";
> String INVALID_MAX_ROWS_VALUE = "XJ063.S";
> String INVALID_FETCH_DIRECTION = "XJ064.S";
> String INVALID_ST_FETCH_SIZE = "XJ065.S";
> String INVALID_MAXFIELD_SIZE = "XJ066.S";
I think the discussion was that when Shreyas added a new similar message
and ita was resolved that adding a generic message and that existing
code could converge to its use over time.
I can add a Jira entry for this. My "itch" is keeping the footprint down
in whatever way possible.
Dan.
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Oy...@Sun.COM.
Daniel John Debrunner wrote:
> I think delaying the comment is fine.
>
> I'm planning to commit this change before the end of this week, assuming
> all the tests run for me.
Great!
> One thing I do need is confirmation that the
> copyright dates are correct in the files you've added. Some of them have
> dates of 1997,2004 which seems unlikely, are all the new files meant to
> have a copyright date of 2005? I can fix this if it is the case.
Yes, 2005 is correct.
> I'm assuming that some performance tests will be run before this code
> makes it as part of a release, comparing performance to 10.1/10.0 and
> the performance impact of enabling query timeout.
Yes, I certainly plan to do performance testing of this.
> rather than a new error XJ074.S, the existing generic error XJ081.S
> (added by Shreyas) could have been used.
OK. Considering e.g. these existing codes (see below), it was not clear
to me what was the preferred way - adding a separate code or using a
generic one.
String INVALID_FETCH_SIZE = "XJ062.S";
String INVALID_MAX_ROWS_VALUE = "XJ063.S";
String INVALID_FETCH_DIRECTION = "XJ064.S";
String INVALID_ST_FETCH_SIZE = "XJ065.S";
String INVALID_MAXFIELD_SIZE = "XJ066.S";
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Oyvind.Bakksjo@Sun.COM wrote:
[on comments about re-use of TimerTasks]
write a comment about this in the code in a subsequent
> patch (for instance when implementing Statement.cancel), unless anybody
> wants me to address this now and submit a new patch.
I think delaying the comment is fine.
I'm planning to commit this change before the end of this week, assuming
all the tests run for me. One thing I do need is confirmation that the
copyright dates are correct in the files you've added. Some of them have
dates of 1997,2004 which seems unlikely, are all the new files meant to
have a copyright date of 2005? I can fix this if it is the case.
I'm assuming that some performance tests will be run before this code
makes it as part of a release, comparing performance to 10.1/10.0 and
the performance impact of enabling query timeout.
I'm also guessing there are other improvements that could be done, such
as tying the lock timeout to the query timeout value.
Two minor comments on the patch
rather than a new error XJ074.S, the existing generic error XJ081.S
(added by Shreyas) could have been used.
EmbeddedStatement now calculates query timeout * 1000 for every
execution, probably minor but might have been better to store the value
as ms in EmbeddedStatement and just divide / 1000 when getQueryTimeout
is called. Seems execute will be called far more often than getQueryTimeout.
Thanks!
Dan.
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Oy...@Sun.COM.
Daniel John Debrunner wrote:
> Oyvind Bakksjo (JIRA) wrote:
>
>
>
>>Hi Dan, thanks for reviewing this patch so quickly.
>>
>>I am fully aware of and share you concern for the performance impact of creating all the TimerTask objects.
>>
>>It is far from ideal.
>>The problem is that the Timer class _forces_ recreation of TimerTask objects, since these can't be reused;
>>when a TimerTask has run or been cancelled, it is pure waste. Trying
>
> to schedule the same task again will
>
>>cause an exception. If it wasn't for this, we could associate a TimerTask with each StatementContext object.
>
>
> This is the kind of case where a comment in the code helps a great deal.
> A comment that says why a new TimerTask is created each time due to the
> requirements of the Java timer scheme. Not everyone will know or
> remember restrictions on TimerTasks. Ane when I looked at the JDK 1.4
> javadoc it wasn't clear to me that that was the intention of the scheme.
> The implication TimerTasks can not be re-used is hidden the exception
> description for adding one to Timer. I would almost read the javadoc as
> you can re-use timer tasks, but a timer task can not be scheduled
> multiple times concurrently.
No, scheduling an already used TimerTask will generate an
IllegalStateException if any of the following are true (I have verified
this):
a) the task has been scheduled but has not yet been run
b) the task has been scheduled and has been run
c) the task has been scheduled and has been cancelled
In other words, TimerTask objects can be scheduled only once, they can
not be reused.
I suggest that I write a comment about this in the code in a subsequent
patch (for instance when implementing Statement.cancel), unless anybody
wants me to address this now and submit a new patch.
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Oyvind Bakksjo (JIRA) wrote:
> Hi Dan, thanks for reviewing this patch so quickly.
>
> I am fully aware of and share you concern for the performance impact of creating all the TimerTask objects.
>
> It is far from ideal.
> The problem is that the Timer class _forces_ recreation of TimerTask objects, since these can't be reused;
> when a TimerTask has run or been cancelled, it is pure waste. Trying
to schedule the same task again will
> cause an exception. If it wasn't for this, we could associate a TimerTask with each StatementContext object.
This is the kind of case where a comment in the code helps a great deal.
A comment that says why a new TimerTask is created each time due to the
requirements of the Java timer scheme. Not everyone will know or
remember restrictions on TimerTasks. Ane when I looked at the JDK 1.4
javadoc it wasn't clear to me that that was the intention of the scheme.
The implication TimerTasks can not be re-used is hidden the exception
description for adding one to Timer. I would almost read the javadoc as
you can re-use timer tasks, but a timer task can not be scheduled
multiple times concurrently.
Dan.
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Oyvind Bakksjo (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12313431 ]
Oyvind Bakksjo commented on DERBY-31:
-------------------------------------
Hi Dan, thanks for reviewing this patch so quickly.
I am fully aware of and share you concern for the performance impact of creating all the TimerTask objects. It is far from ideal. The problem is that the Timer class _forces_ recreation of TimerTask objects, since these can't be reused; when a TimerTask has run or been cancelled, it is pure waste. Trying to schedule the same task again will cause an exception. If it wasn't for this, we could associate a TimerTask with each StatementContext object.
This performance impact will, however, only affect queries with a timeout value set. As such, it is a tradeoff - you can get timeouts, but that will slow down your execution.
If it turns out that the calls to checkCancellationFlag() seriously affect performance, these calls could be decimated by doing the call only for each n-th row. (It sure will be nice to get that performance regression test, so we'll see the actual impact.) For the time being, I can do some rudimentary testing of this myself.
I agree a separate module for the timer might be overkill. As for the interface, my idea was that more methods than getCancellationTimer() could be added as needs arose for Timers for other purposes. It would be up to the implementing class whether to actually return the same Timer object. I guess it would depend on the duration of the TimerTasks and the responsiveness requirements whether to use multiple Timers or just a single one.
I meant to support milliseconds use internally and seconds at the JDBC API level. I guess it would be more consistent if I used milliseconds in the language PreparedStatement interface as well. And yes, I'll fix throwing an exception on negative timeout values.
> 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
> Assignee: Oyvind Bakksjo
> Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Amit Handa (JIRA)" <de...@db.apache.org>.
[ http://nagoya.apache.org/jira/browse/DERBY-31?page=comments#action_56813 ]
Amit Handa commented on DERBY-31:
---------------------------------
Just to correct what I have commenetd earlier,
The solution can be from the time a query is executeXXX is called till the time
executeXXX fetches a ResultSet handle. If this time is greater than the time set,
throw SQLException
> Statement.setQueryTimeout() support.
> ------------------------------------
>
> Key: DERBY-31
> URL: http://nagoya.apache.org/jira/browse/DERBY-31
> Project: Derby
> Type: New Feature
> Components: JDBC
> Environment: ALL
> Reporter: Ali Demir
>
> 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://nagoya.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
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Oyvind Bakksjo (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
Oyvind Bakksjo updated DERBY-31:
--------------------------------
Attachment: svn.status
Output of the 'svn status' command.
> 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
> Assignee: Oyvind Bakksjo
> Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12314795 ]
Daniel John Debrunner commented on DERBY-31:
--------------------------------------------
Øyvind's patch committed revision 208650. (into trunk)
> 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
> Assignee: Oyvind Bakksjo
> Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, Derby-31.patch, QueryTimer.java, derbyall_report.txt
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Oy...@Sun.COM.
Daniel John Debrunner wrote:
> Oyvind Bakksjo (JIRA) wrote:
>
>
>> [ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
>>
>>Oyvind Bakksjo updated DERBY-31:
>>--------------------------------
>>
>> Attachment: DERBY-31.svn.status
>> DERBY-31.svn.diff
>> derbyall_report.txt
>>
>>Attached patch addresses the following issues:
>>* Throw exception on negative input to setQueryTimeout()
>>* Test case for the above
>>* Use milliseconds instead of seconds in the PreparedStatement interface and GenericPreparedStatement class
>>* Exclude SetQueryTimeoutTest from DerbyNet and DerbyNetClient, since these environments don't yet support the new functionality (will create a fix for the DerbyClient driver later
>
>
> I'll look at this again, before it can be committed you will need to
> have an ICLA on file at Apache. Ideally all contributors need to have
> ICLA's on file, at least any that are contributing more than minor changes.
>
> http://db.apache.org/source.html
> http://www.apache.org/licenses/#clas
I signed and faxed the ICLA on May 19th, so that should be in order.
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Oyvind Bakksjo (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
>
> Oyvind Bakksjo updated DERBY-31:
> --------------------------------
>
> Attachment: DERBY-31.svn.status
> DERBY-31.svn.diff
> derbyall_report.txt
>
> Attached patch addresses the following issues:
> * Throw exception on negative input to setQueryTimeout()
> * Test case for the above
> * Use milliseconds instead of seconds in the PreparedStatement interface and GenericPreparedStatement class
> * Exclude SetQueryTimeoutTest from DerbyNet and DerbyNetClient, since these environments don't yet support the new functionality (will create a fix for the DerbyClient driver later
I'll look at this again, before it can be committed you will need to
have an ICLA on file at Apache. Ideally all contributors need to have
ICLA's on file, at least any that are contributing more than minor changes.
http://db.apache.org/source.html
http://www.apache.org/licenses/#clas
Dan.
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Oyvind Bakksjo (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
Oyvind Bakksjo updated DERBY-31:
--------------------------------
Attachment: DERBY-31.svn.status
DERBY-31.svn.diff
derbyall_report.txt
Attached patch addresses the following issues:
* Throw exception on negative input to setQueryTimeout()
* Test case for the above
* Use milliseconds instead of seconds in the PreparedStatement interface and GenericPreparedStatement class
* Exclude SetQueryTimeoutTest from DerbyNet and DerbyNetClient, since these environments don't yet support the new functionality (will create a fix for the DerbyClient driver later
Derbyall has been run with two failures, report attached.
StmtCloseFunTest - hard to tell if it's related to my changes, very little output from the test about what exactly failed.
miscerrors - doesn't seem related
> 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
> Assignee: Oyvind Bakksjo
> Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, Derby-31.patch, QueryTimer.java, derbyall_report.txt
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by de...@db.apache.org.
The following issue has been updated:
Updater: Daniel John Debrunner (mailto:djd@debrunners.com)
Date: Mon, 11 Oct 2004 10:35 AM
Comment:
Change to new feature and JDBC component
Changes:
type changed from Improvement to New Feature
Component changed to JDBC
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/DERBY-31?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DERBY-31
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DERBY-31
Summary: Statement.setQueryTimeout() support.
Type: New Feature
Status: Unassigned
Priority: Major
Project: Derby
Components:
JDBC
Assignee:
Reporter: Ali Demir
Created: Mon, 4 Oct 2004 11:54 AM
Updated: Mon, 11 Oct 2004 10:35 AM
Environment: ALL
Description:
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.
---------------------------------------------------------------------
JIRA INFORMATION:
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
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12313375 ]
Daniel John Debrunner commented on DERBY-31:
--------------------------------------------
Some general comments on the patch
- giving the patch file a specific name (rather than svn-diff) helps out the committers (and anyone else) when the patch is downloaded
- try to resist the temptation to clean up the code (e.g. your javadoc fixes), it makes it much hard to review the patch and see the real changes. If you want to do such cleanup that's great, by a separate patch is much better.
Specific comments
- the patch needs to be re-submitted, it doesn't apply for me on messages_en.properties and SQLState,
just update your codeline and see if a merge is needed.
In general I believe the functionality is correct and clearly implemented but I have a few minor concerns and one major one.
The major one is the performance impact of this fix . Every time StatementContext.setInUse() is called a new CancelQueryTask object will be created, that will be very expensive for queries, imagine a ResultSet of one milllion rows, that's at least one million short lived objects being created and going through gc. Derby tries to limit object creation during execution to be not be a function of the number of rows, except where (indirectly) mandated by the JDBC spec. The impact of the checkCancellationFlag() calls is also of concern.
- I wonder if a module is really needed for the time task, a simpler approach would be just to have the Monitor return the TimerTask directly. The TimerFactory interface doesn't add any value over TimerTask itself, and its one method ie badly named. I don't see any reason this timer should be limited to cancellation events.
- The code seems to vary a bit about choosing to use milli-seconds or seconds, it has to be seconds at the JDBC level, but then internally you use milli-seconds and then back to seconds in the langauage PreparedStatement interface. I would stick to seconds since that is the granuality at the api level and only convert to ms at the TimerTask level. You might consider using the constant 0L if you are passing zero into a long method argument, means the method resolution remains the same if ever the method is overloaded with an int argument.
- For the JDBC Statement.setQueryTimeout() Derby traditionally checks that the input value is valid, thus I think an exception should be thrown for a negative timeout. (and that's the specified JDBC behaviour)
In spite of those comments (I'm very picky) I believe this is a good patch, especially for your first. :-) In the open source world it's probably a 50-50 call as to if the patch could be committed as-is and these items subsequently addressed or they need to be addressed first. Some folks on the list may be concerned about the performance impact of this. I would like to see the functionality committed but the performance addressed before this becomes part of any release.
[but the patch can only be committed there was a newer version that applied cleanly]
It's actually great to have a concrete implementation because the issues with it give me some ideas on how it possibly could be done without such a performance impact, but that will have to be a later e-mail. I need to run :-)
> 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
> Assignee: Oyvind Bakksjo
> Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Oyvind Bakksjo (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
Oyvind Bakksjo updated DERBY-31:
--------------------------------
Attachment: svn.diff
Output of the 'svn diff' command.
> 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
> Assignee: Oyvind Bakksjo
> Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Please see inline.
~ Shreyas
Daniel John Debrunner wrote:
>Shreyas Kaushik wrote:
>
>
>
>>I investigated this approach by having a private boolean variable in the
>>EmbedStatement
>>class and trying to set its value through a setter method. This setter
>>method is called only
>>when the time out happens on the TimerTask. So, from this point I was
>>wondering how
>>to transfer the control to the "thread A" to signal the statement to
>>stop executing.
>>
>>
>
>The timer expiring would just call cancel on the statment object, thus
>moving the problem of thread notification to the cancel method. That's
>why I've been saying along, implementing cancel is a prerequiste for
>setQueryTimeout.
>
>
>
>>In addition to the above queries should this implementation of
>>cancelling a Statement
>>involve going much below the current level where I am working.
>>( I was thinking along the lines of activation or may be much below this
>>in the engine).
>>
>>
>
>Not sure if this was a question, but I think cancel() does go deep into
>the engine, and is a non-trivial fix.
>
>I know Derby today does handle a Thread within Derby being interrupted,
>using Thread.interrupt(). If you looked at that code, I think it could
>be modified to handle cancel().
>
>
Interrupting a Thread in Derby causes the connection also to close, right?
Was this implementation by design?
>Of course, the actual behaviour of cancel needs to be resolved before
>you start implementing it. These are the questions that need to be
>answered (and probably more) to give an idea of what the behaviour would be.
>
>What happens if the Statement object isn't active
>What happens if the Statement object is closed
>Is the Statement object closed by a cancel?
>Does a cancel cause the transaction to be rolled back,
>or just the statement, or does it just stop execution and not rollback
>any changes made so far?
>Note that a PreparedStatement and CallableStatement inherit Statement
>behaviour so cancel needs to work on them.
>What are all the states that a Statement object could be in when cancel
>is called on it?
>
>
We should get things going here. If developers/users on the alias reply
as to what exactly
is their understanding of cancel and what they need out of it. You are
right I can start to
implement only after we have arrived at some maeningful opinion on this.
>Dan.
>
>
>
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Shreyas Kaushik wrote:
> I investigated this approach by having a private boolean variable in the
> EmbedStatement
> class and trying to set its value through a setter method. This setter
> method is called only
> when the time out happens on the TimerTask. So, from this point I was
> wondering how
> to transfer the control to the "thread A" to signal the statement to
> stop executing.
The timer expiring would just call cancel on the statment object, thus
moving the problem of thread notification to the cancel method. That's
why I've been saying along, implementing cancel is a prerequiste for
setQueryTimeout.
> In addition to the above queries should this implementation of
> cancelling a Statement
> involve going much below the current level where I am working.
> ( I was thinking along the lines of activation or may be much below this
> in the engine).
Not sure if this was a question, but I think cancel() does go deep into
the engine, and is a non-trivial fix.
I know Derby today does handle a Thread within Derby being interrupted,
using Thread.interrupt(). If you looked at that code, I think it could
be modified to handle cancel().
Of course, the actual behaviour of cancel needs to be resolved before
you start implementing it. These are the questions that need to be
answered (and probably more) to give an idea of what the behaviour would be.
What happens if the Statement object isn't active
What happens if the Statement object is closed
Is the Statement object closed by a cancel?
Does a cancel cause the transaction to be rolled back,
or just the statement, or does it just stop execution and not rollback
any changes made so far?
Note that a PreparedStatement and CallableStatement inherit Statement
behaviour so cancel needs to work on them.
What are all the states that a Statement object could be in when cancel
is called on it?
Dan.
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Please see inline.
~ Shreyas
Daniel John Debrunner wrote:
>Jeremy Boynes wrote:
>
>
>
>>Daniel John Debrunner wrote:
>>
>>
>
>
>
>>>The timer task should just be notifying the thread that is executing the
>>>statement that it needs to be cancelled, not performing the cancel
>>>itself.
>>>
>>>
>>>
>>There is also an implementation of a WorkManager in Geronimo that you
>>could be using; the timer task would hand the workload over to that for
>>processing.
>>
>>
>
>So currently Derby requires that all work within the context of a
>connection is single threaded. That is, only a single thread can be
>active within the engine at a time for a single JDBC connection.
>
>So for query timeout the tricky case is when thread A is executing the
>statement within the engine and is taking a long time, either waiting
>for a lock, in a user function, doing processing without returning rows
>to the user (e.g. a table scan with an aggregate).
>
>In this case the timer thread needs to notify thread A that it need to
>abort its execution and return control to the applicaition, through an
>exception on the JDBC method, e.g. ps.executeQuery() or rs.next(). I
>
I investigated this approach by having a private boolean variable in the
EmbedStatement
class and trying to set its value through a setter method. This setter
method is called only
when the time out happens on the TimerTask. So, from this point I was
wondering how
to transfer the control to the "thread A" to signal the statement to
stop executing.
In addition to the above queries should this implementation of
cancelling a Statement
involve going much below the current level where I am working.
( I was thinking along the lines of activation or may be much below
this in the engine).
>The
>rollback must occur in the context of thread A, not another thread.
>Thus, I believe the WorkManager from Geronimo will not be suitable.
>
>[the engine correctly handles multiple threads each with their own
>connection, and it correctly handles multiple threads concurrently (not
>advised) or serially using a single connection. In the concurrent case
>using a single connection, each thread is blocked at the JDBC layer
>until the other thread completes its jdbc method call.]
>
>Dan.
>
>
>
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jeremy Boynes wrote:
> Daniel John Debrunner wrote:
>> The timer task should just be notifying the thread that is executing the
>> statement that it needs to be cancelled, not performing the cancel
>> itself.
>>
>
> There is also an implementation of a WorkManager in Geronimo that you
> could be using; the timer task would hand the workload over to that for
> processing.
So currently Derby requires that all work within the context of a
connection is single threaded. That is, only a single thread can be
active within the engine at a time for a single JDBC connection.
So for query timeout the tricky case is when thread A is executing the
statement within the engine and is taking a long time, either waiting
for a lock, in a user function, doing processing without returning rows
to the user (e.g. a table scan with an aggregate).
In this case the timer thread needs to notify thread A that it need to
abort its execution and return control to the applicaition, through an
exception on the JDBC method, e.g. ps.executeQuery() or rs.next(). The
rollback must occur in the context of thread A, not another thread.
Thus, I believe the WorkManager from Geronimo will not be suitable.
[the engine correctly handles multiple threads each with their own
connection, and it correctly handles multiple threads concurrently (not
advised) or serially using a single connection. In the concurrent case
using a single connection, each thread is blocked at the JDBC layer
until the other thread completes its jdbc method call.]
Dan.
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel John Debrunner wrote:
> Shreyas Kaushik wrote:
>
>
>>~ I looked at the possible usage of java.util.Timer and
>>java.util.TimerTask.
>> Although it may seem to be a correct approach to use them at the first
>> thought it has some practical drwbacks to its usage in this scneario.
>>
>
>
>
>>~ Using the Timer and TimerTask may have just one thread, but the above
>>mentioned drawback could be a major performance hit causing more latency in
>>statement execution.
>
>
> Or you work within the Timer scheme, and implement TimerTasks as
> recommended, from java.util.Timer
>
> "Timer tasks should complete quickly."
>
> The timer task should just be notifying the thread that is executing the
> statement that it needs to be cancelled, not performing the cancel itself.
>
There is also an implementation of a WorkManager in Geronimo that you
could be using; the timer task would hand the workload over to that for
processing.
--
Jeremy
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Shreyas Kaushik wrote:
> ~ I looked at the possible usage of java.util.Timer and
> java.util.TimerTask.
> Although it may seem to be a correct approach to use them at the first
> thought it has some practical drwbacks to its usage in this scneario.
>
> ~ Using the Timer and TimerTask may have just one thread, but the above
> mentioned drawback could be a major performance hit causing more latency in
> statement execution.
Or you work within the Timer scheme, and implement TimerTasks as
recommended, from java.util.Timer
"Timer tasks should complete quickly."
The timer task should just be notifying the thread that is executing the
statement that it needs to be cancelled, not performing the cancel itself.
Dan.
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
~ I looked at the possible usage of java.util.Timer and java.util.TimerTask.
Although it may seem to be a correct approach to use them at the first
thought it has some practical drwbacks to its usage in this scneario.
~ At a time there is a only *one* Timer per system running( as earlier
discussions in this list have suggested ). If that is the case a call to the
statement's setQueryTimeout() method will a create TimerTask that is
responsible for timing out of that statement and may be a subsequent cancel
when the timeout happens.
~ Now when one statement's timeout mechanism is at work on the Timer thread,
other statements have timeout's set on them they'll have to wait until the
current task is completed( eventhough others are scheduled for immediate
execution on the Timer). I tested this behaviour by writing a program that
schedules multiple tasks on the Timer for immediate execution.
~ If the current statement that is occupying the Timer times out and calls a
cancel() and the cancel takes a while to return ( this could be because of
various reasons), statements will queue up waiting for the Timer.
~ Using the Timer and TimerTask may have just one thread, but the above
mentioned drawback could be a major performance hit causing more latency in
statement execution.
To summarize with using the Timer and TimerTask we'll basically use a
single-threaded approach as there will be one centralized timer.So I
guess we need to work a solution to get this through. We may consider
using the solution I proposed.
And also pointers on what all should happen during cancel() will be helpful.
As different people may see the cancel behaviour differently as Dan
mentioned
in one of his mails.
~ Shreyas
Daniel John Debrunner wrote:
>Shreyas Kaushik (JIRA) 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.
>>
>>
>>
>
>I think a detailed explanation of what you believe cancel and
>setQueryTimeout functionality should be would be very useful. I'm not
>sure closing the activation actually results in the expected behaviour.
>
>I also think the timing should be centralized per database or per
>system, using java.util.Timer and TimerTask. With your implementation a
>Thread per statement will be created when using query timeouts. Creating
>threads is expensive in Java and there was a request against Cloudscape
>to create one background thread per system, rather than the current case
>of one per database. This is to handle the situation where there are
>hundreds or thousands of databases per system.
>
>Dan.
>
>
>
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Please see below for my answers
~ Shreyas
Daniel John Debrunner wrote:
>Shreyas Kaushik wrote:
>
>
>>Please see below for my replies.
>>
>>~ Shreyas
>>
>>Daniel John Debrunner wrote:
>>
>>
>
>
>
>>>I think a detailed explanation of what you believe cancel and
>>>setQueryTimeout functionality should be would be very useful. I'm not
>>>sure closing the activation actually results in the expected behaviour.
>>>
>>>
>>>
>>>
>>setQueryTimeout should go set the time until which a Query can execute
>>after the executeQuery
>>is called. In other words it specifies what is the upper limit for me to
>>fetch the data.
>>
>>
>
>Can you explain your reasoning behind this. The only guidance I see is
>from the javadoc which does not mention anything about the application.
>Maybe it is explained more in the tutorial book?
>
>>From javadoc 1.4.2
>
>public void setQueryTimeout(int seconds)
> throws SQLException
>
>Sets the number of seconds the driver will wait for a Statement object
>to execute to the given number of seconds. If the limit is exceeded, an
>SQLException is thrown.
>
>
My reasoning was, when the time out set has expired the statement object
should stop
executing whatever it is doing. I used the term "executeQuery" in one of
my previous
replies was becuase in my current patch I had covered this time out for
executeQuery().
>
>
>
>>Regarding the cancel() it is same as what JDBC spec says. One thread
>>should be able to cancel the execution
>>of a statement from another thread. When query times or otherwise a call
>>to cancel() should stop the execution
>>of a statement and clear up all resources.
>>
>>
>
>Having cancel() call System.exit() would fulfill your description of the
>functionality, but would probably not be what people would expect. :-)
>
>How does a cancel affect the thread that is executing the statement,
>what is the affect on the state of the database, connection or
>transaction, statement, jdbc objects etc? What happens if the statement
>isn't executing, or has a result set open but is not active in Derby?
>These are the issues that need to be thought about and written down.
>
>
What would be a good starting point to do this ? Some pointers here
would help.
>My guess is that the people who have been active on this discussion may
>each have a slightly different (or completely different) idea of what a
>cancel does, given it is not completely defined by the JDBC spec. Anyone
>looking at your patch cannot begin to review it until they understand
>what *detailed* functionality you believe your are implementing. Then
>there may be discussions on is it the required functionality, and does
>the patch actually implement the intended functionality.
>
>
Ok agreed. Once we reach a concenses on the topics that you have talked
about
above a patch can be circulated here and driven to conclusion.
>
>Dan.
>
>
>
>
>
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Shreyas Kaushik wrote:
> Please see below for my replies.
>
> ~ Shreyas
>
> Daniel John Debrunner wrote:
>> I think a detailed explanation of what you believe cancel and
>> setQueryTimeout functionality should be would be very useful. I'm not
>> sure closing the activation actually results in the expected behaviour.
>>
>>
> setQueryTimeout should go set the time until which a Query can execute
> after the executeQuery
> is called. In other words it specifies what is the upper limit for me to
> fetch the data.
Can you explain your reasoning behind this. The only guidance I see is
from the javadoc which does not mention anything about the application.
Maybe it is explained more in the tutorial book?
>From javadoc 1.4.2
public void setQueryTimeout(int seconds)
throws SQLException
Sets the number of seconds the driver will wait for a Statement object
to execute to the given number of seconds. If the limit is exceeded, an
SQLException is thrown.
> Regarding the cancel() it is same as what JDBC spec says. One thread
> should be able to cancel the execution
> of a statement from another thread. When query times or otherwise a call
> to cancel() should stop the execution
> of a statement and clear up all resources.
Having cancel() call System.exit() would fulfill your description of the
functionality, but would probably not be what people would expect. :-)
How does a cancel affect the thread that is executing the statement,
what is the affect on the state of the database, connection or
transaction, statement, jdbc objects etc? What happens if the statement
isn't executing, or has a result set open but is not active in Derby?
These are the issues that need to be thought about and written down.
My guess is that the people who have been active on this discussion may
each have a slightly different (or completely different) idea of what a
cancel does, given it is not completely defined by the JDBC spec. Anyone
looking at your patch cannot begin to review it until they understand
what *detailed* functionality you believe your are implementing. Then
there may be discussions on is it the required functionality, and does
the patch actually implement the intended functionality.
Dan.
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Please see below for my replies.
~ Shreyas
Daniel John Debrunner wrote:
>Shreyas Kaushik (JIRA) 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.
>>
>>
>>
>
>I think a detailed explanation of what you believe cancel and
>setQueryTimeout functionality should be would be very useful. I'm not
>sure closing the activation actually results in the expected behaviour.
>
>
setQueryTimeout should go set the time until which a Query can execute
after the executeQuery
is called. In other words it specifies what is the upper limit for me to
fetch the data.
Regarding the cancel() it is same as what JDBC spec says. One thread
should be able to cancel the execution
of a statement from another thread. When query times or otherwise a call
to cancel() should stop the execution
of a statement and clear up all resources.
>I also think the timing should be centralized per database or per
>system, using java.util.Timer and TimerTask. With your implementation a
>Thread per statement will be created when using query timeouts. Creating
>threads is expensive in Java and there was a request against Cloudscape
>to create one background thread per system, rather than the current case
>of one per database. This is to handle the situation where there are
>hundreds or thousands of databases per system.
>
>
Ok creating threads are costly, but the time out is set per query , if
there are multiple queries excuting
at the same time with different time out's how should this be handled?
>Dan.
>
>
>
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Shreyas Kaushik (JIRA) 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.
>
I think a detailed explanation of what you believe cancel and
setQueryTimeout functionality should be would be very useful. I'm not
sure closing the activation actually results in the expected behaviour.
I also think the timing should be centralized per database or per
system, using java.util.Timer and TimerTask. With your implementation a
Thread per statement will be created when using query timeouts. Creating
threads is expensive in Java and there was a request against Cloudscape
to create one background thread per system, rather than the current case
of one per database. This is to handle the situation where there are
hundreds or thousands of databases per system.
Dan.
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Shreyas Kaushik (JIRA)" <de...@db.apache.org>.
[ 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] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Oyvind Bakksjo (JIRA) wrote:
> Here is an implementation of Statement.setQueryTimeout.
>
> The patch includes a new functional test in the jdbcapi testsuite.
>
> It is my first Derby patch, so I ask any reviewer; please, use your magnifying glass and be critical. :)
>
> May I suggest that Dan looks at it, since he has given me the most feedback on this issue? (I don't write this to exclude other volunteers, I just think that Mr. "Someone" already has enough on his todo list, given all the requests of the kind "Can someone review this patch?". ;o)
I will look at it over this weekend. I think it missed the train for
10.1, but it could potentially go into a future 10.1 release (ie. on the
branch) because it (I assume) is just runtime code, no upgrade or
persistent issues.
Dan.
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Oyvind Bakksjo (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12313258 ]
Oyvind Bakksjo commented on DERBY-31:
-------------------------------------
Here is an implementation of Statement.setQueryTimeout.
The patch includes a new functional test in the jdbcapi testsuite.
It is my first Derby patch, so I ask any reviewer; please, use your magnifying glass and be critical. :)
May I suggest that Dan looks at it, since he has given me the most feedback on this issue? (I don't write this to exclude other volunteers, I just think that Mr. "Someone" already has enough on his todo list, given all the requests of the kind "Can someone review this patch?". ;o)
Notes/thoughts/issues:
* Perhaps other ResultSet classes than [Bulk]TableScanResultSet should check for cancellation, but I think these are the most important ones to begin with. I will look into this later.
* Currently, no kind of substatement execution has any timeout value set. This includes update operations on updatable resultsets, triggers, alter table operations etc.
* To a certain extent, I have cleaned up javadoc warnings in the files touched by me, since they made it difficult for me to see whether I had introduced any new javadoc warnings myself.
I'm running derbyall and will attach the results once it's finished.
> 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
> Assignee: Oyvind Bakksjo
> Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Oyvind Bakksjo (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
Oyvind Bakksjo updated DERBY-31:
--------------------------------
Comment: was deleted
> 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
> Assignee: Oyvind Bakksjo
> Fix For: 10.2.0.0
> Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, derbyall_report.txt
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Shreyas Kaushik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=history ]
Shreyas Kaushik updated DERBY-31:
---------------------------------
Attachment: QueryTimer.java
This is the implementation of the Query Timer that triggers the statement cancelling on time out.
> 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
[jira] Closed: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
Rick Hillegas closed DERBY-31.
------------------------------
Resolution: Fixed
Appears to be implemented now in embedded and network drivers.
> Statement.setQueryTimeout() support.
> ------------------------------------
>
> Key: DERBY-31
> URL: http://issues.apache.org/jira/browse/DERBY-31
> Project: Derby
> Issue Type: New Feature
> Components: JDBC
> Environment: ALL
> Reporter: Ali Demir
> Assigned To: Oyvind Bakksjo
> Fix For: 10.2.0.0
>
> Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, derbyall_report.txt
>
>
> 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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Ali Demir (JIRA)" <de...@db.apache.org>.
[ http://nagoya.apache.org/jira/browse/DERBY-31?page=comments#action_56831 ]
Ali Demir commented on DERBY-31:
--------------------------------
When a time out is set to n millis, and if the query takes n+m millis, then caller would expect that time out occurs around n millis and not wait until n+m. Also, when the timeout occurs, the processing of the query should have been stopped and there should not be any locks held after timeout. Therefore, a simple solution that simply checks how long the query processing is taking is not enough. The internals of the system need to know that it should stop the query and release any locks held by it when the timeout occurs.
> Statement.setQueryTimeout() support.
> ------------------------------------
>
> Key: DERBY-31
> URL: http://nagoya.apache.org/jira/browse/DERBY-31
> Project: Derby
> Type: New Feature
> Components: JDBC
> Environment: ALL
> Reporter: Ali Demir
>
> 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://nagoya.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
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Satheesh Bandaram (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12363737 ]
Satheesh Bandaram commented on DERBY-31:
----------------------------------------
Is this issue ready to be RESOLVED and/or CLOSED? Oyvind seems to have done pretty much all activities that need to be done for this issue.
> 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
> Assignee: Oyvind Bakksjo
> Fix For: 10.2.0.0
> Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, derbyall_report.txt
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Amit Handa (JIRA)" <de...@db.apache.org>.
[ http://nagoya.apache.org/jira/browse/DERBY-31?page=comments#action_56812 ]
Amit Handa commented on DERBY-31:
---------------------------------
One solution can be to check for time(set a flag) when setQueryTimeout() is set.
Every time any executeXXX() method is called, check whether query timed out
with differrence from the present time and the flag set earlier.
If time out throw SQLException else do nothing
> Statement.setQueryTimeout() support.
> ------------------------------------
>
> Key: DERBY-31
> URL: http://nagoya.apache.org/jira/browse/DERBY-31
> Project: Derby
> Type: New Feature
> Components: JDBC
> Environment: ALL
> Reporter: Ali Demir
>
> 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://nagoya.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
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ]
Daniel John Debrunner updated DERBY-31:
---------------------------------------
Fix Version: 10.2.0.0
> 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
> Assignee: Oyvind Bakksjo
> Fix For: 10.2.0.0
> Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, Derby-31.patch, QueryTimer.java, derbyall_report.txt
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira