[
https://jira.jboss.org/jira/browse/JBTM-488?page=com.atlassian.jira.plugi...
]
Andrew Dinn closed JBTM-488.
----------------------------
Resolution: Done
Added a mode switch to participants so that they switch from sending Completed to sending
GetStatus once the resend period has reached the maximum limit and at least one Completed
message has been sent. The switch is deactivated and the period restored to the initial
value if a message comes in from the coordinator (e.g. a Status or a resent Complete). The
switch is also automatically set to send getStatus when a recovered participant is
activated.
Fixed GetStatus methods for coordinator and participant processors so they send an
InvalidState soap fault when a GetStatus is received for an unknown
participant/participant stub.
Modified participant soap fault handling so that an InvalidState soap fault received while
checking the participant status causes an automatic compensate of the participant (this is
presumed abort since the coordinator does not know that the participant exists). Any other
fault is handled by calling the participant error method. In either case any record of the
participant in the transaction log is deleted.
Completed BA Participants need to switch from sending Completed
requests to sending GetStatus requests in order to detect coordinator crashes
---------------------------------------------------------------------------------------------------------------------------------------------
Key: JBTM-488
URL:
https://jira.jboss.org/jira/browse/JBTM-488
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: WS-T Implementation
Reporter: Andrew Dinn
Assignee: Andrew Dinn
Fix For: 4.6
A BA participant can be left forever in state Completed if the coordinator crashes
between completion of the participant and close or cancel of the business activity in
which it is enlisted. In this case there is a participant log record in the participant
host transaction log and no record of the transacttion or participant in the coordinator
host transaction log. This means that the participant will continue sending Completed
messages to the coordinator even after reboot of the participant host. The BA spec
_requires_ the coordinator to ignore such messages. Thenett result is garbage in the
participant log and garbage messages on the network.
The participant is at liberty to dispatch a GetStatus message in place of the Completed
message, either during normal operation or at reboot. The coordinator must reply with a
Status message identifying the participant state or it may dispatch a soap fault. This can
be used to identify that the participant is no longer active.
The current implementation should be modified to switch from sending Completed messages
to sending GetStatus messages. During normal operation this should occur after some number
of resends have failed to elicit a response. During recovery this should occur when the
participant is reinstated. If a valid Status message is received the participant should
revert to sending Completed messages and continue to do so until a state change occurs or
the appropriate criterion is met for switching to sending GetStatus messages again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira