db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4687) Avoid unnecessary round-trip for rollback in the client driver
Date Tue, 22 Jun 2010 22:47:49 GMT

    [ 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.


Mime
View raw message