Quoting Hannes Erven <[EMAIL PROTECTED]>:
Hi Hannes,
> 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).
>
We do remove the callback whenever there is a timeout. In fact this happens
even before Callback.timeout() is called:
timer.schedule(new TimerTask() {
public void run() {
callbacks.remove(callback.getID());
try {
callback.timeout();
} catch (TimedOutException e) {
e.printStackTrace();
}
}
}, timeout);
Please let me know if I'm missing your point. My thinking is that this problem
is simply the result of Java Timer needing more time to cleanup all the
coordinators under heavy load conditions...
Regards,
--dasarath
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
