Major Description
The current WSBA client API allows the client to invoke the complete operation independent from the close operation. In the current persistence implementation complete is implemented, inter alia, by calling BasicAction.prepare and close is implemented by calling BasicAction.phase2Commit.. The call to BasicAction.prepare leaves a transaction record in the log in state COMMITTING rather than state PREPARED. If a crash occurs before the client sends a close request then the recovery code will attempt to roll forward the activity by calling phase2Commit even though the client has not yet requested that the close should happen. If the client dispatches the close request after the recovery code has run it will receive a NoSuchTransaction exception which is highly misleading since the activity has in fact been successfully closed.
The correct behaviour is only to call BasicAction.prepare during close processing. If complete processing is necessare (i.e if there are CoordinatorCompletion participants registered) then the exchange of complete/completed messages should be done by the BA Coordinator class before it attempts to execute a close. The close itself should be implemented by calling BasicAction.End to perform a 2 phase commit. This will ensure that a log record is only written when a close for the activity has been initiated and hence that any record written after the prepare will initiate a valid roll forward of the activity during recovery.
