[EMAIL PROTECTED] 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.
