db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject svn propchange: r619958 - svn:log
Date Fri, 08 Feb 2008 19:37:41 GMT
Author: mamta
Revision: 619958
Modified property: svn:log

Modified: svn:log at Fri Feb  8 11:37:41 2008
------------------------------------------------------------------------------
--- svn:log (original)
+++ svn:log Fri Feb  8 11:37:41 2008
@@ -1 +1,52 @@
 Merging changes 618788, 619279 and 619772 into 10.3 codeline for DERBY-3304.
+
+For reference, copying the commit comments for each of these revisions that are getting merged
into 10.3 codeline
+
+*********commit comments for 619772****************
+DERBY-3304
+Some code cleanup in GenericLanguageConnectionContext.endTransactionActivationHandling so
the code is more readable.
+No functionality change, just consolidated various if statements and used some local variables
to replace repeated
+method calls like a.getResultSet() and a.getResultSet().returnsRows()
+*********end of commit comments for 619772*********
+
+
+*********commit comments for 619279****************
+This is a followup commit for DERBY-3304 based on various comments. It does following
+1)The existing method resetActivations in GenericLanguageConnectionContext has been renamed
to better reflect it's
+functionality. It will be now called endTransactionActivationHandling since it gets called
for commit/rollback.
+2)The javadoc comments for resetActivations(now called endTransactionActivationHandling)
were not valid. Fixed that in
+this commit.
+3)Took out the redundant code about setting the holdability to false if we were in rollback.
It was needed earlier
+because the method that took care of activations at rollback time needed to check the holdability.
That method
+(BaseActivation.reset) does not check holdability anymore and hence we do not need to set
the activations to false
+holdability when we are dealing with rollback.
+4)Lastly, JDBC api for Connection.commit does not ask for clearing of warnings and hence
we should not have code to
+clear the warnings at the time of commit. I removed the warning clearing code from resetActivations(now
called
+endTransactionActivationHandling) in GenericLanguageConnectionContext.
+*********end of commit comments for 619279*********
+
+
+*********commit comments for 618788****************
+DERBY-3304
+This commit addresses two issues.
+First of all, it cleanups up reset method in BaseActivation which was doing more than just
bringing the Activation back 
+to pre-execution state. The method had to make itself aware of holdability and what kind
of resultset it was dealing with
+before closing or clearing the row of the resultset. The reason for this behavior is commit
code path was relying on
+Activation.reset to do more than just bringing the activation to pre-execution state. I fixed
this by moving this code
+from BaseActivation.reset to GenericLanguageConnectionContext.resetActivations.
+
+Additionally, in the new code in GenericLanguageConnectionContext.resetActivations, I added
the code to not close the
+language result sets associated with activations that do not return rows even if activation
may have holdability set to
+false. This will ensure that a commit inside a java procedure will not inadvertantly close
the resultset associated with
+the java procedure call.
+
+Additionally, I copied some of the cleanup work(as shown below) from BaseActivation.reset
into
+new code in GenericLanguageConnectionContext.resetActivations
+   a.clearHeapConglomerateController();
+   if (!a.isSingleExecution())
+      a.clearWarnings();
+
+This code above was always getting executed at the time of commit before my commit and because
of that, I decided to copy
+it in GenericLanguageConnectionContext.resetActivations. If anyone has any comments on this,
please let me know.
+*********end of commit comments for 618788*********
+


Mime
View raw message