[
https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan closed DERBY-3441.
----------------------------------
Closing the issue.
Some cleanup has been done as part of DERBY-3581, by removing a unnecessary
flag.
A comment on the code below, from Connection.completeReset(boolean,boolean):
if (closeStatementsOnClose) {
// NOTE: This is to match previous behavior.
// Investigate and check if it is really necessary.
this.isolation_ = TRANSACTION_UNKNOWN;
java.util.Set keySet = openStatements_.keySet();
for (java.util.Iterator i = keySet.iterator(); i.hasNext();) {
Object o = i.next();
((Statement) o).reset(closeStatementsOnClose);
}
} else {
// Must reset transaction isolation level if it has been changed.
if (isolation_ != Connection.TRANSACTION_READ_COMMITTED) {
// This might not fare well with connection pools, if it has
// been configured to deliver connection with a different
// isolation level, i.e. it has to set the isolation level again
// when it returns connection to client.
// TODO: Investigate optimization options.
setTransactionIsolationX(Connection.TRANSACTION_READ_COMMITTED);
}
}
I have not been able to enter the for-loop, as there aren't any open
statements. They are being closed before we get this far, so I'm wondering if
we could replace the for loop with an assert. Maybe this code comes from
previous functionality or behavior. If 'closeStatementsOnClose' is false, it
means JDBC statement caching is enabled.
After that, one would have to check if the handling of the isolation level can
be merged as well, in which case the 'closeStatementsOnClose' variable can be
removed.
This would have to be checked when using both ClientConnectionPoolDataSource
and ClientXADataSource. My investigations so far have been focused on the
connection pool data source.
> Determine and implement a proper procedure for resetting a prepared statement
> for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.1.3
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.1.3
>
> Attachments: derby-3441-1a-statement_reset.diff,
> derby-3441-1b-statement_reset.diff, derby-3441-1c-statement_reset.diff,
> derby-3441-2a-minor_am_refactoring.diff,
> derby-3441-3a-extract_setTransactionIsolationX.diff
>
>
> Initial investigations indicate there are no existing suitable methods to
> properly reset a prepared (or callable) statement for reuse with a statement
> pool.
> A full reset is too heavy weight and defeats the purpose of statement
> pooling, but a proper procedure should be achievable by reusing existing
> pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
