[
https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lily Wei updated DERBY-4653:
----------------------------
Attachment: DERBY-4653-2.diff
Thank you so much, Kristian. That is such a good suggestion. I will give it a
try.
I add the patch for Connection.flowcommit() so it won't flow if we don't need
to perform the unnecessary round trip.
Please see DERBY-4653-2.diff. I also try to add the test for testing saving
commit. I add an extra commit on J2EEDataSourceTest to test the fix. 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?
About making Connection.flowrollback not doing the round trip, It is not as
straight forward as detecting isUnitofWork_ only. I think the check has to
happen along with isXAConnection_ and where we are in the rollback state. I
will keep working on that today. However, I do think that it is safe to commit
DERBY-4653-2.diff. I will suggest to open a new JIRA for rollback only depend
on how to test Connection.flowcommit DRDA related protocol.
> 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: 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 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.
