|
If you were logged in you would be able to see more operations.
|
|
|
|
File Attachments:
|
|
|
Issue Links:
|
Reference
|
|
This issue relates to:
|
|
DERBY-827
Performance can be improved by re-using language ResultSets across Activation executions.
|
|
|
|
|
|
|
|
| Urgency: |
Normal
|
| Issue & fix info: |
Repro attached
|
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.
|
|
Description
|
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. |
Show » |
| Repository |
Revision |
Date |
User |
Message |
| ASF |
#633778 |
Wed Mar 05 06:03:22 UTC 2008 |
mamta |
I am backporting quite a few checkins from trunk into 10.3 codeline for DERBY-3304 and
DERBY-3404.
The main functionality that is getting ported is when a user initiates a rollback through
JDBC Connection object, the rollback should not close the resultsets that do not return
rows.
This functionality was checked in into trunk through multiple checkins for DERBY-3304 and
those checkins are 628130, 629926, 631481. In addition, there was a supporting checkin into
trunk by Knut for DERBY-3404 (revision 629712) on which the 3 checkins listed earlier rely.
I am backporting all of these 4 checkins from trunk into 10.3 codeline.
The tests have run fine with no new regression.
I am including checkin comments for all these revisions for easy reference here.
**********checkin comments for 628130)**************
DERBY-3304
DERBY-3037
DERBY-1585
I am adding a test case to check for the resultset from the java procedure call when the
java procedure has done a rollback inside it. This test shows that in trunk, after checkin
602991 for DERBY-1585, a procedure does not return a resultset if there was a rollbck
inside the procedure with resultset creation before rollback. This behavior is different
than what happens in 10.2 codeline. In 10.2, a procedure will return a *closed* resultset
if there was a rollback inside the procedure. But a procedure should not return closed
result sets, so it appears that trunk is behaving correctly and 10.2's behavior was
incorrect.
**********end of checkin comments for 628130)*******
**********checkin comments for 629712)**************
DERBY-3404: EmbedResultSet.getString() returns wrong value after auto-commit with
CLOSE_CURSORS_AT_COMMIT
**********end of checkin comments for 629712)*******
**********checkin comments for 629926)**************
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,
**********end of checkin comments for 629926)*******
**********checkin comments for 631481)**************
Checking in code cleanup for DERBY-3304. This code cleanup is based on Knut's review of my
earlier commit 629926. No functionality has changed, but code will be now much easier to
read.
**********end of checkin comments for 631481)*******
|
| Files Changed |
MODIFY
/db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
MODIFY
/db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/master/jdk16/closed.out
MODIFY
/db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
MODIFY
/db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/master/closed.out
MODIFY
/db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/ResultSetTest.java
MODIFY
/db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/jdbc/EmbedStatement.java
MODIFY
/db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceTest.java
MODIFY
/db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/master/nestedCommit.out
MODIFY
/db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/tests/lang/LangProcedureTest.java
|
|
Bug
Reopened
