db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shreyas Kaushik <Shreyas.Kaus...@Sun.COM>
Subject Re: Implementing Statement.cancel()
Date Wed, 04 May 2005 11:08:33 GMT


Daniel John Debrunner wrote:

>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
>happening.
>
>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.
>  
>
Dan,

Any pointers here ?

~ Shreyas

>Dan.
>
>
>  
>

Mime
View raw message