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-4653) Avoid unnecessary round-trip for commit/rollback in the client driver
Date Wed, 26 May 2010 17:52:37 GMT

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

Kristian Waagan commented on DERBY-4653:

Lily wrote:
However, if the behavior go back to the round-trip scenario, the test has no way knowing other
than functionality is working. Does anyone has a good suggest to test the DRDA protocol for
commit making round trip or not?
A few suggestions (none of them really optimal):
 - add different trace points on the client for the cases where a commit is flowed or not,
then parse the trace file
   (this change could actually help debugging in production environments)
 - enable statement logging on the server and parse the log looking for the number of commits
(assuming an "unnecessary" commit produces a log message)
 - some kind of timed test doing as many commits as possible (hard to set the thresholds,
probably not a viable solution?)
 - add special debug code, or exploit poor state encapsulation in the client driver
  (for instance, can the DRDA "sequence number" be used, or more likely, maybe the client
side "transaction id"?)

Another related task would be to inspect the code to make sure the variable 'inUnitOfWork_'
is in sync with reality.

> 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:
>            Reporter: Kristian Waagan
>            Assignee: Lily Wei
>            Priority: Minor
>         Attachments: DERBY-4653-1.diff, DERBY-4653-2.diff
> 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
> 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.

View raw message