db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4653) Avoid unnecessary round-trip for commit/rollback in the client driver
Date Wed, 09 Jun 2010 00:33:14 GMT

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

Kathey Marsden commented on DERBY-4653:

wrt to some of Kristian's comments and a few things I talked to Lily about today.

 I  too think it would be good to test just for client and with regular, pooled, and xa datasources.

I think if the test runs just for client we should always count on the getTransactionID()
method being there and can take out the skipping logic all together.  I think the system table
query can come out all together.  I tend to think the getTransactionID() check is good enough,
but the protocol trace parsing would be ok too.

I agree the comment about embedded should come out of am.LogicalConnection.

For the flowRollback() change I think the condition to return if inUnitOfWork should not be
in the if block. I think the StatementPoolingTest failures you were seeing with it set that
way may be because the state of  inUnitOfWork may be wrong somehow where hold cursors and
pooled connections are involved, probably an existing issue that needs to be tracked down
before committing this change.  Lily and I tried to reproduce it outside the test with the
code   but we were  not quite able to get in the same state as StatementPoolingTest.

> 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: _sds_0, DERBY-4653-1.diff, DERBY-4653-2.diff, DERBY-4653-3_withrollback.diff,
DERBY-4653-4_withcommitrollbacktest.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
> 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