You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Andreas Korneliussen (JIRA)" <de...@db.apache.org> on 2006/03/22 14:26:26 UTC

[jira] Commented: (DERBY-787) cursor closed as a sideeffect of closing another cursor with the same name on another connection

    [ http://issues.apache.org/jira/browse/DERBY-787?page=comments#action_12371420 ] 

Andreas Korneliussen commented on DERBY-787:
--------------------------------------------

I think I have found what caused this issue.

The "UPDATE WHERE CURRENT OF SQLCUR0" is prepared and compiled and produces an Activation (generated code) which can be reused by other connections, since the compiled code is cached.

The generated code keeps a cursor name and it will during execution look up a CursorActivation based on the cursor name. 
The CursorActivation is the code for the cursor (the select statement).
During execution, the class CurrentOfResultSet has a method called getCursor(). It finds the CursorActivation for the LanguageConnectionContext, however it has a check that the prepared statement object for the CursorActivation is the same as it was whem first compiling "UPDATE WHERE ..".  This will only be the case if it was the same statement string which produced the cursors.

Here is some debug of the LanguageConnectionContext.lookupCursorActivation(..)
1st connection:
(XID = 562), (SESSIONID = 1), (DATABASE = cis), (DRDAID = null), [BaseActivation: Source: select * from t1 where a=1 FOR UPDATE, ObjectName =582f8014-010a-21d6-1c29-00000016c7a0, BaseActivation: Source: UPDATE "APP"."T1" SET "A"=?,"B"=? WHERE CURRENT OF "SQLCUR0", ObjectName =6839c016-010a-21d6-1c29-00000016c7a0]

2nd connection:
(XID = 566), (SESSIONID = 2), (DATABASE = cis), (DRDAID = null), [BaseActivation: Source: select * from t1 where a=2 FOR UPDATE, ObjectName =e03f4017-010a-21d6-1c29-00000016c7a0, BaseActivation: Source: UPDATE "APP"."T1" SET "A"=?,"B"=? WHERE CURRENT OF "SQLCUR0", ObjectName =6839c016-010a-21d6-1c29-00000016c7a0]

As you can see, the Connections do not share the CursorActivation code.

Fixing this issue could be to remove the check that the prepared statement objectname for the cursor is the same.  
If anyone knows a case were this would be incorrect, please let me know. 


> cursor closed as a sideeffect of closing another cursor with the same name on another connection
> ------------------------------------------------------------------------------------------------
>
>          Key: DERBY-787
>          URL: http://issues.apache.org/jira/browse/DERBY-787
>      Project: Derby
>         Type: Bug
>   Components: SQL
>     Versions: 10.1.2.1
>  Environment: Java 1.4
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen
>  Attachments: CursorIsClosedIssue.java
>
> I was writing some tests for the Scrollable updatable ResultSet feature, and  found some tests failing with 
> ERROR XCL07: Cursor 'SQLCUR0' is closed. Verify that autocommit is OFF.
> in ResultSet.updateRow(). 
> The test does the following:
> 1. set up a connection, and run a query which selects one tuple
> 2. update the tuple using updateXXX and updateRow
> 3. rollback the transaction and close the connection
> Then, repeat the process, however this time use a different string in the query.  This time updateRow() may fail with the error above. 
> The problem has been reproduced on forward only, updatable resultsets.
> Workaround:
> It does not seem to fail if I
> a, set another cursorname on the statement object,
> b, use the same query string.
> I will attach the program to reproduce the problem. Below is the output:
> ~:/<3>db-derby-10.1.2.1-bin/lib> java -cp /home/ak136785/devel/derbytesting/derbytest/build/classes/:derby.jar derbytest.CursorIsClosedIssue
> 1,1,19,Tuple 1
> 2,2,21,Tuple 2
> ERROR XCL07: Cursor 'SQLCUR0' is closed. Verify that autocommit is OFF.
>         at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
>         at org.apache.derby.impl.sql.execute.CurrentOfResultSet.getCursor(Unknown Source)
>         at org.apache.derby.impl.sql.execute.CurrentOfResultSet.openCore(Unknown Source)
>         at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
>         at org.apache.derby.impl.sql.execute.NormalizeResultSet.openCore(Unknown Source)
>         at org.apache.derby.impl.sql.execute.UpdateResultSet.setup(Unknown Source)
>         at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source)
>         at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(Unknown Source)
>         at derbytest.CursorIsClosedIssue.runTest(CursorIsClosedIssue.java:80)
>         at derbytest.CursorIsClosedIssue.main(CursorIsClosedIssue.java:103)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira