db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Date Wed, 09 Mar 2005 17:47:58 GMT
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.]


View raw message