db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-787) cursor closed as a sideeffect of closing another cursor with the same name on another connection
Date Wed, 22 Mar 2006 13:26:26 GMT
    [ 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


Mime
View raw message