[
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-7_withflowcommittest_comment_update_diff.txt
I attached an updated version of
'DERBY-4653-7_withflowcommittest_comment_update_diff.txt', with the following
changes:
- simplified the reflection code somewhat
- JavaDoc edits
- replaced tabs with spaces and some formatting changes (long lines)
The patch looks okay, I have the following comments:
a) I'm not thrilled by adding the LogicalConnection.getTransactionID method
just for testing purposes (when we have another mechanism we could use), but I
won't object.
b) The argument 'expectednumtransaction' isn't used.
c) The comment in the actual test is slightly inaccurate. Since the test case
is run with autocommit on, the commit will be flowed at rs.close() such that
none of the calls to commit() will cause a flow to the server.
I'm +0.9 for commit :)
I'll need to read up on the problems regarding rollback. I suppose most
connection pools will issue a rollback rather than a commit to be sure the
connection state is "clean", which is why it would be good to find an
optimization for rollback as well.
> 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,
> 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.
