You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by ma...@apache.org on 2008/02/21 19:47:19 UTC
svn commit: r629926 - in /db/derby/code/trunk/java:
engine/org/apache/derby/impl/jdbc/ engine/org/apache/derby/impl/sql/conn/
testing/org/apache/derbyTesting/functionTests/tests/lang/
Author: mamta
Date: Thu Feb 21 10:47:17 2008
New Revision: 629926
URL: http://svn.apache.org/viewvc?rev=629926&view=rev
Log:
DERBY-3304
The main purpose of this patch is to fix the rollback handling for resultsets that do not
return rows. An example case for this is a java procedure which has a Connection.rollback
inside it. When the user calls the java procedure, and Connection.rollback is made inside
of it, Derby should not be closing the resultset assoicated with the java procedure call
(that resultset is a CallStatementResultSet). In other words, a user initiated rollback
through JDBC Connection object should leave the resultsets that do not return rows open. In
order to implement this, I had to make changes to ignore resultsets that do not return rows
in
GenericLanguageConnectionContext.endTransactionActivationHandling. As a result of this
change, for the eg case given above, the activation assoicated with the java procedure
will not be reset (which also means that, CallStatementResultSet.close will not be called)
inside GenericLanguageConnectionContext.endTransactionActivationHandling.
But the code inside CallStatementResultset.close() took care of the closed dynamic resultset
and it took out the closed dynamic resultset from the list of resultsets that would be
available to user through the Statement.getResultSet api. With my changes through this
patch, we are going to skip the CallStatementResultset.close during
GenericLanguageConnectionContext.endTransactionActivationHandling which means that we have
to deal with those closed dynamic resultsets on our own. I did that part of logic
changes in EmbedStatement.processDynamicResults
EmbedStatement.processDynamicResults used to check if the JDBC Resultset is closed by
directly checking the field isClosed in the EmbedResultSet. But it is not sufficient to
check only JDBC Resultset. We need to check the underlying language Resultset too to
determine if the dynamic resultset is closed. There is no direct api on EmbedResultset
which will return a boolean after checking the JDBC Resultset and language Resulset. Instead,
there is a method called EmbedResultSet.checkIfClosed. This method will throw an exception
if it finds the JDBC ResultSet or language ResultSet closed. So, my changes in
EmbedStatement.processDynamicResults make a call to EmbedResultSet.checkIfClosed and if
there is an exception thrown, then we know that the resultset is closed and hence we should
move to the next resultset.
In addition to these code changes, I have added a new test to LangProcedureTest. The new
java procedure is defined to return 2 dynamic resultsets. One of these resultsets is
created before Connection.rollback inside the java procedure. The other dynamic resultset
is created after Connection.rollback. As as result of Connection.rollback, the first
dynamic resultset will be closed but the second one will remain open. The test makes sure
that only one dynamic resultset is returned by the java procedure.
Also, made one minor change in LangProcedureTest for an existing test. The test at line 804
was getting a resultset from the Statement object without asserting that there are no more
resultsets. The resultset object would have been null anyways in this test because there
are no open resulsets from the Java procedure. Because of this, I took out the redundant
code of getting null resultset object from Statement using getResultset,
Modified:
db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedStatement.java
db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/LangProcedureTest.java
Modified: db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedStatement.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedStatement.java?rev=629926&r1=629925&r2=629926&view=diff
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedStatement.java (original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedStatement.java Thu Feb 21 10:47:17 2008
@@ -1643,8 +1643,15 @@
return null;
// ignore closed result sets.
- if (lrs.isClosed)
- return null;
+ try {
+ //following will check if the JDBC ResultSet or the language
+ //ResultSet is closed. If yes, then it will throw an exception.
+ //So, the exception indicates that the ResultSet is closed and
+ //hence we should ignore it.
+ lrs.checkIfClosed("");
+ } catch (SQLException ex) {
+ return null;
+ }
lrs.setDynamicResultSet(callStatement);
Modified: db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java?rev=629926&r1=629925&r2=629926&view=diff
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java (original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java Thu Feb 21 10:47:17 2008
@@ -2699,7 +2699,11 @@
/**
If we are called as part of rollback code path, then we will reset all
- the activations.
+ the activations that have resultset returning rows associated with
+ them. DERBY-3304 Resultsets that do not return rows should be left
+ alone when the rollback is through the JDBC Connection object. If the
+ rollback is caused by an exception, then at that time, all kinds of
+ resultsets should be closed.
If we are called as part of commit code path, then we will do one of
the following if the activation has resultset assoicated with it. Also,
@@ -2738,11 +2742,26 @@
continue;
}
+ ResultSet activationResultSet = null;
+ boolean resultsetReturnsRows = false;
+ if (a.getResultSet() != null) {
+ activationResultSet = a.getResultSet();
+ resultsetReturnsRows = activationResultSet.returnsRows();
+ }
+
if (forRollback) {
- //Since we are dealing with rollback, we need to reset the
- //activation no matter what the holdability might be or no
- //matter whether the associated resultset returns rows or not.
- a.reset();
+ if (activationResultSet != null)
+ if (resultsetReturnsRows)
+ //Since we are dealing with rollback, we need to reset
+ //the activation no matter what the holdability might
+ //be provided that resultset returns rows. An example
+ //where we do not want to close a resultset that does
+ //not return rows would be a java procedure which has
+ //user invoked rollback inside of it. That rollback
+ //should not reset the activation associated with
+ //the call to java procedure because that activation
+ //is still being used.
+ a.reset();
// Only invalidate statements if we performed DDL.
if (dataDictionaryInWriteMode()) {
ExecPreparedStatement ps = a.getPreparedStatement();
@@ -2752,9 +2771,7 @@
}
} else {
//We are dealing with commit here.
- if (a.getResultSet() != null) {
- ResultSet activationResultSet = a.getResultSet();
- boolean resultsetReturnsRows = activationResultSet.returnsRows();
+ if (activationResultSet != null) {
//if the activation has resultset associated with it, then
//use following criteria to take the action
if (resultsetReturnsRows){
Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/LangProcedureTest.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/LangProcedureTest.java?rev=629926&r1=629925&r2=629926&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/LangProcedureTest.java (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/LangProcedureTest.java Thu Feb 21 10:47:17 2008
@@ -801,16 +801,33 @@
.execute("create procedure procWithRollback(p1 int) parameter style JAVA READS SQL DATA dynamic result sets 1 language java external name 'org.apache.derbyTesting.functionTests.tests.lang.LangProcedureTest.rollbackInsideProc'");
drs1 = prepareCall("CALL procWithRollback(3)");
drs1.execute();
- rs = drs1.getResultSet();
//Following shows that the rollback inside the java procedure will
//cuase procedure to return no resultset (A procedure does
//not return closed resultsets). In 10.2 codeline though, java
//procedure returns a closed resultset if there is a rollback
//inside the java procedure.
JDBC.assertNoMoreResults(drs1);
-
JDBC.assertClosed(rs1);
JDBC.assertClosed(resultSet);
+
+ //Following shows that the rollback inside the java procedure will
+ //only close the resultset created before the rollback. The
+ //resultset created after the rollback will remain open and if it
+ //is a resultset returned through the procedure then it will be
+ //available to the caller of the procedure. Notice that even though
+ //the procedure is defined to 2 return dynamic resultsets, only one
+ //is returned because the other one was closed as a result of
+ //rollback.
+ s.execute("create procedure procWithRollbackAnd2Resulsets"+
+ "(p1 int) parameter style JAVA READS SQL DATA dynamic "+
+ "result sets 2 language java external name "+
+ "'org.apache.derbyTesting.functionTests.tests.lang.LangProcedureTest.rollbackInsideProcWith2ResultSets'");
+ drs1 = prepareCall("CALL procWithRollbackAnd2Resulsets(3)");
+ drs1.execute();
+ rs = drs1.getResultSet();
+ JDBC.assertDrainResults(rs);
+ JDBC.assertNoMoreResults(drs1);
+
s.execute("drop table dellater1");
s.execute("drop table dellater2");
conn.setAutoCommit(oldAutoCommit);
@@ -1133,6 +1150,35 @@
ps.setInt(1, p1);
data[0] = ps.executeQuery();
conn.rollback();
+ conn.close();
+ }
+
+ /**
+ * A test case for DERBY-3414. An explicit rollback inside the procedure
+ * should close all the resultsets created before the call to the
+ * procedure and any resultsets created inside the procedure including
+ * the dynamic resultsets. But the resultset created after the rollback
+ * should stay open
+ *
+ * @param p1
+ * @param data
+ * @throws SQLException
+ */
+ public static void rollbackInsideProcWith2ResultSets(int p1,
+ ResultSet[] data1,
+ ResultSet[] data2)
+ throws SQLException {
+ Connection conn = DriverManager.getConnection(
+ "jdbc:default:connection");
+ PreparedStatement ps = conn.prepareStatement(
+ "select * from t1 where i = ?");
+ ps.setInt(1, p1);
+ data1[0] = ps.executeQuery();
+ conn.rollback();
+ ps = conn.prepareStatement(
+ "select * from dellater1 where i = ?");
+ ps.setInt(1, p1);
+ data2[0] = ps.executeQuery();
conn.close();
}