[
https://issues.apache.org/jira/browse/DERBY-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881429#action_12881429
]
Kathey Marsden commented on DERBY-4687:
---------------------------------------
I guess for this one, somehow the Statement.willTickleServer() logic may have
to be moved earlier for open statements so that we flow the rollback if any of
the statements are open on the server. We want to avoid it happening twice
though,. I guess it would be good to start with a break point in the
willTickleServer() code to see where it get s called and if it can somehow be
moved earlier before the decision to flow the rollback is made.
> Avoid unnecessary round-trip for rollback in the client driver
> --------------------------------------------------------------
>
> Key: DERBY-4687
> URL: https://issues.apache.org/jira/browse/DERBY-4687
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.6.1.0
> Reporter: Lily Wei
> Assignee: Lily Wei
> Priority: Minor
> Fix For: 10.7.0.0
>
>
> Per fixing DERBY-4653, the same issue is happening for Connection.rollback().
> The methods Connection.rollback() in the client driver cause a round-trip to
> the server even if the rollback is unnecessary (i.e. there is nothing to 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 and
> does not create regression.
> // Even if we're not in a transaction, all open result sets will be
> closed.
> // So we could probably just return if we're not in a transaction
> // using the following code:
> // if (!this.inUnitOfWork)
> // return;
> The protocol tests should be added too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
