Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-4687

Avoid unnecessary round-trip for rollback in the client driver

    Details

    • Urgency:
      Low
    • Issue & fix info:
      Newcomer
    • Bug behavior facts:
      Performance

      Description

      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.

        Issue Links

          Activity

          Hide
          kmarsden Kathey Marsden added a comment -

          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.

          Show
          kmarsden Kathey Marsden added a comment - 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.
          Hide
          kmarsden Kathey Marsden added a comment -

          Triage for 10.8. Marked urgency low since the commit case is usually most important for performance. Changing from bug to improvement.

          Show
          kmarsden Kathey Marsden added a comment - Triage for 10.8. Marked urgency low since the commit case is usually most important for performance. Changing from bug to improvement.
          Hide
          kristwaa Kristian Waagan added a comment -

          For normal operation commits are most important, but I assume that most connection pools that want to ensure clean connections would perform a rollback instead of a commit.
          In applications with many short-lived business transactions, this may result in an unnecessary round-trip each time the logical connection is returned to the pool. We had the same issue earlier with the isolation level, but this was solved with the session state piggy-backing mechanism (enabled the client to know what the isolation level is on the server side).

          Show
          kristwaa Kristian Waagan added a comment - For normal operation commits are most important, but I assume that most connection pools that want to ensure clean connections would perform a rollback instead of a commit. In applications with many short-lived business transactions, this may result in an unnecessary round-trip each time the logical connection is returned to the pool. We had the same issue earlier with the isolation level, but this was solved with the session state piggy-backing mechanism (enabled the client to know what the isolation level is on the server side).

            People

            • Assignee:
              lilywei Lily Wei
              Reporter:
              lilywei Lily Wei
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development