Derby
  1. Derby
  2. DERBY-341

Client should disallow XAConnection getConnection() when a global transaction has been started and a logical connection has already been obtained

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.1.1.0
    • Fix Version/s: None
    • Component/s: JDBC
    • Urgency:
      Normal

      Description

      If a logical connection has already been obtained, client should disallow XAConnection getConnection if a global transaction has been started and a logical connection has already been obtained

      Repro:

      With the client the script below does not give an error.

      ij> connect 'wombat;create=true';
      ij> disconnect;
      ij> xa_datasource 'wombat';
      ij> xa_connect user 'APP' password 'xxx';
      Connection number: 3.
      ij> – start new transaction
      xa_start xa_noflags 0;
      ij> xa_getconnection;
      ij> – Should not be able to get connection again
      xa_getconnection;

      With embedded we get.
      ERROR XJ059: Cannot close a connection while a global transaction is still active.

        Activity

        Hide
        Kathey Marsden added a comment -

        Looking briefly at this issue I see that
        NetConnection.flowReconnect
        does not actually flow anything, but rather sets up a cache of what to flow on the first sql statement. The trouble is that the next thing that flows may not be an sql statement but rather could be an xa call or
        maybe other things. This will cause unpredictable results on the next call.

        Some options might be
        1) Get rid of the optimization and just flow the reset when we call getConnection.
        2) Instead of keeping a separate cache, write the bytes into the agents write buffer in Reply.java, so it won't be missed regardless of the call.

        Regardless, a fair amount of pull apart and put back together is required to fix this bug.
        Since it is a negative case, I suggest it be deferrred to 10.2 with a comment in the release notes.

        Show
        Kathey Marsden added a comment - Looking briefly at this issue I see that NetConnection.flowReconnect does not actually flow anything, but rather sets up a cache of what to flow on the first sql statement. The trouble is that the next thing that flows may not be an sql statement but rather could be an xa call or maybe other things. This will cause unpredictable results on the next call. Some options might be 1) Get rid of the optimization and just flow the reset when we call getConnection. 2) Instead of keeping a separate cache, write the bytes into the agents write buffer in Reply.java, so it won't be missed regardless of the call. Regardless, a fair amount of pull apart and put back together is required to fix this bug. Since it is a negative case, I suggest it be deferrred to 10.2 with a comment in the release notes.
        Hide
        Kathey Marsden added a comment -

        Moving to 10.2

        Show
        Kathey Marsden added a comment - Moving to 10.2
        Hide
        Kathey Marsden added a comment -

        Changing fix version to Unknown as I will not have time to fix it for 10.2 and it is currently unassigned.

        Show
        Kathey Marsden added a comment - Changing fix version to Unknown as I will not have time to fix it for 10.2 and it is currently unassigned.
        Hide
        Mike Matrigali added a comment -

        Triaged July 10, 2009: assigned normal urgency.

        Show
        Mike Matrigali added a comment - Triaged July 10, 2009: assigned normal urgency.

          People

          • Assignee:
            Unassigned
            Reporter:
            Kathey Marsden
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development