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: Implementing Statement.cancel()
Date Mon, 02 May 2005 17:11:19 GMT
Oyvind.Bakksjo@Sun.COM wrote:

> I've been looking at implementing Statement.cancel(), and later,
> Statement.setQueryTimeout().

<snip: good progress on implementation leading to this question>

> What I have been testing so far is using the
> LanguageConnectionContext.getStatementContext() method through the lcc
> reference available to both EmbedStatement and BasicNoPutResultSet.
> However, it seems odd to me to go through a "connection context" object
> to get the statement context. I'm not sure this is the right way to do
> it. What if, for instance, there are multiple open statements on the
> same connection? What statement's context object is returned?

That method will return the currently active top statement context, the
statement being executed in the engine at the current time.

If the application has multiple JDBC statements open then only one of
them is active, ie. activly executing in the engine at any time, thus
LanguageConnectionContext.getStatementContext() will return a
StatementContext related to that execution.

However, if the SQL statement being executed by the application's JDBC
statement contains server side logic (triggers, procedures or
functions), then the statement context may represent any SQL statement
executed by the server logic.

E.g. application has three open statements (Statement,
PreparedStatements or CallableStatements)

S1 prepared but no active ResultSet
S2 executed, open ResultSet, application processing rows
S3 executed, open ResultSet, application processing rows

If the application has control, then there is no active
StatementContext, since no active execution for that Connection is

Application executes S3.next()which takes some time

Between the start of this S3.next() method and it returning, the engine
is actively executing that statement. During this time no other activity
for that Connection can be handled by the engine, it is blocked by
synchronization at the JDBC level. That is if S2.next(), or S1.execute()
is called, they will block on the java synchronization.

At this point the active top StatementConxtext returned by
LanguageConnectionContext.getStatementContext() will correspond to S3.

But if S3's SQL statement included a function that in turn executed a
SQL Statement using server-side JDBC (statement S4 using
jdbc:default:connection), then while S4 was executing (S4.execute() or
next() etc. for its ResultSet), the active top StatementContext would
correspond to S4.

So, quick summary, that method is not suitable for finding the correct
StatementContext from EmbedStatement.cancel().

I'll look into how I think you should track down the StatementContext.

View raw message