I have logged an enhancement request to help track this issue:
https://issues.apache.org/jira/browse/DERBY-3908
Regards,
-Rick
Knut Anders Hatlen wrote:
Kristian Waagan <[EMAIL PROTECTED]> writes:
Rick Hillegas wrote:
Hi Dirk,
Yes, Derby does support Statement.setQueryTimeout(), at least as
verified by the Derby regression test
org.apache.derbyTesting.functionTests.tests.lang.SetQueryTimeoutTest. That's
a good defense if you suspect in advance that your queries may
ramble on. It leaves the lingering issue of how to cancel a runaway
query that you (or someone else) didn't limit before the query
started.
Correct.
It should be noted though, that your mileage may vary with
setQueryTimeout. I assume that mechanism requires the engine to check
a flag to see if it should abort, and if the code is "stuck" in an
area where there are no such checks you might have to wait longer than
the specified timeout value.
If anyone has been using it, it would be nice to get some feedback on
how well it is working/behaving.
Is it possible to use the same machinery to add support for timing out
a running transaction?
Is this something that would be needed by many users?
I suppose the client (dba, user etc) would normally have an idea
whether the transaction/query will finish in a few seconds or a few
days before issuing it.
There is an undocumented feature that you may use in embedded mode:
Connection conn = ....;
org.apache.derby.impl.jdbc.EmbedConnection embConn =
((org.apache.derby.impl.jdbc.EmbedConnection) conn;
embConn.cancelRunningStatement();
It uses the same mechanism as the statement timeout. That is, it sets a
flag that is checked now and then during execution.
Note that this method is not part of Derby's public API and could change
or be removed any time.
