[
http://issues.apache.org/jira/browse/DERBY-817?page=comments#action_12362901 ]
Kathey Marsden commented on DERBY-817:
--------------------------------------
One additional thing that I noticed in reviewing the patch for DERBY-210 was
that Connection.java had this comment
which to the best of my knowledge is not true on either count and should be
considered in evaluating the role of
CommitAndRollbackListeners_ in the client.
// Some statuses of DERBY objects may be invalid on server after both
// commit and rollback. For example,
// (1) prepared statements need to be re-prepared
// after both commit and rollback
// (2) result set will be unpositioned on server after both commit and
rollback.
// If they depend on both commit and rollback, they need to get on
CommitAndRollbackListeners_.
> Improvements to Network Client driver - analyze/improve use of java
> collection classes in the code
> --------------------------------------------------------------------------------------------------
>
> Key: DERBY-817
> URL: http://issues.apache.org/jira/browse/DERBY-817
> Project: Derby
> Type: Improvement
> Components: Network Client
> Versions: 10.1.1.0, 10.2.0.0, 10.1.2.0
> Reporter: Deepa Remesh
> Priority: Minor
>
> When working on DERBY-210, following came up as cases for possible
> improvements/optimizations:
> * Bryan pointed out that synchronization is missing when accessing
> openStatements_ and CommitAndRollbackListeners_ , which are members of
> org.apache.derby.client.am.Connection class.
> * Bryan suggested adding convenience methods to access these lists.
> * Do we need to add Lobs to CommitAndRollbackListeners_? In case of Lobs, I
> cannot see anything else being done with it other than adding and removing
> from this list. Is there any other purpose for adding Lobs to this list?
> * Do we need to add PreparedStatements to CommitAndRollbackListeners_? A
> comment in the code mentions they are added to the list because prepared
> statements need to be re-prepared after commit/rollback. As I understand,
> this is not required. Also, in the code, only internal statements like
> statements used for auto-generated keys etc are being re-prepared. Maybe,
> this can be avoided.
> * Do we need to add all result sets to the HashTable
> 'positionedUpdateCursorNameToResultSet_' in SectionManager? All ResultSets
> get added to this Hashtable though only ResultSets from positioned update
> statements are retrieved and used from this table. There seems to be some
> extra work going on in client driver in just adding and removing "all" result
> sets to this hashtable. I think this can be avoided. Can we avoid adding
> result sets from positioned update statements to this hashtable? Some
> analysis can be done to see if this hashtable itself can be removed.
> The items listed above are independent and sub-tasks may be opened to work on
> them individually. Some of them are questions and depending on findings, they
> may not need further work.
> These issues were discussed in the following threads:
> http://www.nabble.com/-jira-Updated%3A-%28DERBY-210%29-Network-Server-will-leak-prepared-statements-if-not-explicitly-closed-by-the-user-until-the-connection-is-closed-t914229.html#a2371474
> http://www.nabble.com/-jira-Commented%3A-%28DERBY-210%29-Network-Server-will-leak-prepared-statements-if-not-explicitly-closed-by-the-user-until-the-connection-is-closed-t915113.html#a2373800
--
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
