Uploaded image for project: 'JBoss Transaction Manager'
  1. JBoss Transaction Manager
  2. JBTM-1303

WS-AT client can return from commit before all participants have committed

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 6.later
    • Component/s: XTS
    • Labels:
      None

      Description

      Normally, when a WS-AT client calls commit, the coordinator will wait until all participants are committed before returning to the client. This ensures that the Client doesn't continue processing until all changes have been made permanent and visible.

      If the participant takes longer than 30s to return the 'committed' message, the participant logs the fact and then returns to the client. The recovery mechanism will then handle the sending of the commit message to the participant. As WS-AT doesn't support heuristics, the participant is guaranteed to commit eventually, but after at least one recovery scan. This means that the client may think that the work done, in the transaction, is now visible when in actual fact it is not quite yet.

      Potential solutions

      Return CommittingException

      As a JBoss only solution (it would break the standard), we could throw a CommittingException when the coordinator returns control to the client after delegating to the recovery manager to commit the outstanding participant(s). The client then know that the work will commit, but it's not completed yet. Handling of this exception could be to either ignore it, or poll the resource until the change is visible. This could work for both synchronous and asynchronous clients.

      Delay the return until participants really have committed.

      This is unlikely to work for the (JBoss only) synchronous client as the connection is unlikely to stay open long enough. However, it could work for the asynchronous scenario, but would require the client to increase the timeout to include the amount of time it takes for the coordinator to give up waiting for committed and delegate to the recovery manager, plus enough time for the recovery scan to occur and receive the committed message. Also, the client endpoint information would need to be stored in the recovery log, so that the recovery manager can attempt notification (which would also need implementing).

      Document the issue for now

      ... and implement a solution if/when we get a user with this problem.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  paul.robinson Paul Robinson
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated: