[
https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4653:
-----------------------------------
Attachment: derby-4653-8a-alternative_test.diff
Attached patch 8a, which implements an alternative test parsing the client
connection trace file.
It's a bit more extensive than the existing test, but may not add any extra
value.
Uploaded for reference, as it may come in useful for debugging purposes.
> Avoid unnecessary round-trip for commit 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,
> DERBY-4653-5_withflowcommitrollback.diff,
> DERBY-4653-6_withflowcommitrollback.diff,
> DERBY-4653-7_withflowcommittest.diff,
> DERBY-4653-7_withflowcommittest_comment_update_diff.txt,
> DERBY-4653-7_withflowcommittest_comment_update_diff.txt,
> DERBY-4653-7_withflowcommittest_comment_update_diff_followup.txt,
> derby-4653-8a-alternative_test.diff, ReproTransInProgressAttempt.java,
> 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.
