[
https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875737#action_12875737
]
Kristian Waagan commented on DERBY-4653:
----------------------------------------
Sorry for the short post (it's late here now), but I think there are some
issues with the patch.
Feel free to have another look at it right away, I'll have a look on Monday in
any case.
Also, I'll be happy to help you write the code parsing the trace file (it's
good to keep the existing test) , i.e. something like:
- obtain first connection, run test sequence without redundant commits
- parse trace file to obtain baseline for number of commits
- obtain second connection, run test sequence with many of extra commits
- parse trace file to obtain number of commits
- compare the commit counts
In this case it might be good to factor out the test sequence code into a
method with a boolean telling wheter or not to do the extra commits.
It's fine if you don't implement this test, I may have a go at it if you don't
:)
> 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, 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 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.
