db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
Date Tue, 22 Jan 2008 17:30:34 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mamta A. Satoor updated DERBY-3037:

    Attachment: DERBY3037_patch_not_ready_for_commit_v2_stat.txt

I have a very small patch for the last item left on DERBY-3037 which is to move close of a
single use activation from BasicNoPutResultSet.finishRTS into NoPutResultSetImpl.close. The
patch is attached as DERBY3037_patch_not_ready_for_commit_v2_diff.txt but I have included
the diff here to explain the failure caused by the patch

Index: java/engine/org/apache/derby/impl/sql/execute/BasicNoPutResultSetImpl.java
--- java/engine/org/apache/derby/impl/sql/execute/BasicNoPutResultSetImpl.java(revision 613756)
+++ java/engine/org/apache/derby/impl/sql/execute/BasicNoPutResultSetImpl.java(working copy)
@@ -603,9 +603,6 @@

                        finished = true;
-                       if (isTopResultSet && activation.isSingleExecution())
-                               activation.close();

Index: java/engine/org/apache/derby/impl/sql/execute/NoPutResultSetImpl.java
--- java/engine/org/apache/derby/impl/sql/execute/NoPutResultSetImpl.java(revision 613756)
+++ java/engine/org/apache/derby/impl/sql/execute/NoPutResultSetImpl.java(working copy)
@@ -183,6 +183,9 @@

                isOpen = false;

+               if (isTopResultSet && activation.isSingleExecution())
+                       activation.close();

        /** @see NoPutResultSet#setTargetResultSet */

This change in code causes a failure with lang/nestedCommit.sql. The specific test case inside
nestedCommit.sql has to do with a call to a Java Stored routine (specifically, a function)
which looks as follows
public static int doConnCommitInt() throws Throwable
	Connection conn = DriverManager.getConnection("jdbc:default:connection");
	return 1;

And the stack strace in derby.log for nestedCommit.sql looks as follows
2008-01-21 21:52:49.328 GMT Thread[main,5,main] (XID = 157), (SESSIONID = 0), (DATABASE =
wombat), (DRDAID = null), Failed Statement is: -- call doConnStmt('call doConnStmt(''call
values doConnCommitInt()
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED closed
	at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
	at org.apache.derby.impl.sql.execute.BaseActivation.setCurrentRow(BaseActivation.java:1276)
	at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.setCurrentRow(NoPutResultSetImpl.java:316)
	at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(RowResultSet.java:156)
	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:460)
	at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:425)
	at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:369)
	at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:382)
	at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:338)
	at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:241)
	at org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:229)
	at org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:435)
	at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:509)
	at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
	at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248)
	at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)
	at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
	at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)
	at org.apache.derby.tools.ij.main(ij.java:59)

The reason for the stack failure is that the Language ResultSet associated with the function
call has been closed by the new code in NoPutResultSetImpl.close which was invoked by the
commit inside the user function doConnCommitInt. 

During commit processing, we need to somehow distinguish the fact that the Language ResultSet
is still being constructed and used and hence should not be closed. I would appreciate if
anyone has any ideas on how to achieve this.

> Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
> -------------------------------------------------------------------------------------
>                 Key: DERBY-3037
>                 URL: https://issues.apache.org/jira/browse/DERBY-3037
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:
>            Reporter: Daniel John Debrunner
>            Assignee: Mamta A. Satoor
>             Fix For:,
>         Attachments: DERBY3037_patch_not_ready_for_commit_v2_diff.txt, DERBY3037_patch_not_ready_for_commit_v2_stat.txt,
Derby_3037_AlterTableConstantActionChanges_v1_diff.txt, Derby_3037_AlterTableConstantActionChanges_v1_stat.txt
> DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to be the lifetime
of the activation, but did not fix up the correct calls to ResultSet.close() and ResultSet.finish().
> A language ResultSet's lifetime should be driven by the activation, so activation.close()
should call finish() on its ResultSet.
> EmbedResultSet should call close on its language ResultSet (theResults field) when the
JDBC ResultSet is closed, it should not be calling finish() on its ResultSet.
> See comments in DERBY-827 for some more details and issues.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message