[jira] Updated: (DERBY-4653) Avoid unnecessary round-trip for commit/rollback in the client driver

["Lily Wei (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lily Wei updated DERBY-4653:
----------------------------

    Attachment: DERBY-4653-3_withrollback.diff
                SaveRoundClientDS.java

Thanks to Kristian and Kathey.
I fix the avoid traffic for flowrollback(). We need to just flow rollback when we are in XAConnection.
The patch passed suites.allpackages and derbyall.

To test the fix:
1. Will it be okay if we just reflect the method in ..am.Connection.getTransactionID() and make sure the next transaction is after first commit()()/rollback is a predictable number. After the test is run, there will always be a trace file hanging around for manual inspection. It could be cheating a little bit. However, it is a little easier than test open the trace file and search for the number of occurrences of RDBCMM or something like that.  

> Avoid unnecessary round-trip for commit/rollback in the client driver
> ---------------------------------------------------------------------
>
>                 Key: DERBY-4653
>                 URL: https://issues.apache.org/jira/browse/DERBY-4653
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Network Client
>    Affects Versions: 10.7.0.0
>            Reporter: Kristian Waagan
>            Assignee: Lily Wei
>            Priority: Minor
>         Attachments: _sds_0, DERBY-4653-1.diff, DERBY-4653-2.diff, DERBY-4653-3_withrollback.diff, SaveRoundClientDS.java, SaveRoundClientDS.java
>
>
> The methods Connection.commit() and Connection.rollback() in the client driver cause a round-trip to the server even if the commit/rollback is unnecessary (i.e. there is nothing to commit or 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.
> This issue came up in connection with connection pooling, where a pool implementation always issued a rollback to make sure there was no active transaction on the connection handed out.
> From Connection.flowCommit:
>         // Per JDBC specification (see javadoc for Connection.commit()):
>         //   "This method should be used only when auto-commit mode has been disabled."
>         // However, some applications do this anyway, it is harmless, so
>         // if they ask to commit, we could go ahead and flow a commit.
>         // But note that rollback() is less harmless, rollback() shouldn't be used in auto-commit mode.
>         // This behavior is subject to further review.
>         //   if (!this.inUnitOfWork)
>         //     return;
>         // We won't try to be "too smart", if the user requests a commit, we'll flow a commit,
>         // regardless of whether or not we're in a unit of work or in auto-commit mode.
>         //

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.