[ https://issues.jboss.org/browse/JBTM-1303?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1303: -------------------------------- 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. h3. Potential solutions h4. 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. h4. 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). h4. Document the issue for now ... and implement a solution if/when we get a user with this problem. was: 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. h4. Potential solutions h3. 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. h3. 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). h3. Document the issue for now ... and implement a solution if/when we get a user with this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira