Hi folks,
Dasarath Weeratunge wrote:
The reason the coordinator was kept even after completion of the transaction
was, the at-specification requires that we respond to late messages from
participants. I guess we need to look for a better way to do this. Keeping the
coordinator is just an easy but inefficient way of doing it.
This is also true with WS-BA, so I hope we will find a common solution.
With both transaction types, we have to keep all participant GUIDs and
the final outcome until all timeouts expired to be sure all participants
got the right message.
We could dispose the coordinator object, and only keep those UIDs. I
doubt that this would notably decrease the memory usage since the
coordinator object is just participant UID lists and states. ;-)
Removing, as Wenbing proposed, the transaction from the callback
registry when it finishes seems to be more a workaround than a fix. But
she[1] is certainly right that, if the coordinator is never removed from
the callback registry "manually", the GC wont' ever be able to find and
dispose it.
As far as I known, this never happens with the current implementation: a
timeout in Callbackregistry will only call ATCoordinatorImpl.timeout(),
which prints out a log message and rolls back if the transaction is
undecided. I guess it should suffice to add
Callbackregistry.remove(this) there for a specification-compatible fix
of this issue and another one in terminate() at the right position (that
is, when rolling back after a timeout and either all participants
acknownledged or timed out).
Best regards,
-hannes
1: I hope I googled successfully for the right sex...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
