db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Closed: (DERBY-3441) Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
Date Mon, 23 Jun 2008 10:06:45 GMT

     [ 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.


Mime
View raw message