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] Commented: (DERBY-4687) Avoid unnecessary round-trip for rollback in the client driver
Date Thu, 17 Feb 2011 19:11:24 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995988#comment-12995988

Kristian Waagan commented on DERBY-4687:

For normal operation commits are most important, but I assume that most connection pools that
want to ensure clean connections would perform a rollback instead of a commit.
In applications with many short-lived business transactions, this may result in an unnecessary
round-trip each time the logical connection is returned to the pool. We had the same issue
earlier with the isolation level, but this was solved with the session state piggy-backing
mechanism (enabled the client to know what the isolation level is on the server side).

> Avoid unnecessary round-trip for rollback in the client driver
> --------------------------------------------------------------
>                 Key: DERBY-4687
>                 URL: https://issues.apache.org/jira/browse/DERBY-4687
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Client
>    Affects Versions:
>            Reporter: Lily Wei
>            Assignee: Lily Wei
>            Priority: Minor
>              Labels: Connection, client, derby_triage10_8, rollback
> Per fixing DERBY-4653, the same issue is happening for Connection.rollback().
> The methods Connection.rollback() in the client driver cause a round-trip to the server
even if the rollback is unnecessary (i.e. there is nothing to roll back).
> Comments suggest (see below) that this can be optimized, such that the commands are flowed
to the server only when required. It can be seen that this optimization has been used other
places in the client driver. Never the less, it must be checked that this optimization doesn't
have side-effects and does not create regression.
>     // Even if we're not in a transaction, all open result sets will be closed.
>     // So we could probably just return if we're not in a transaction
>     // using the following code:
>     //     if (!this.inUnitOfWork)
>     //       return;
> The protocol tests should be added too.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message