Tom Jenkinson wrote:
David Lloyd wrote:
Jonathan Halliday wrote:
Register Syncs with the local subordinate and register a single Sync in the parent, using the impl thereof to pass the beforeCompletion call down to the subordinate coordinator. Work needed on the TS side: none for beforeCompletion as it's already exposed. Some to expose afterCompletion and allow some way for commit|rollback to indicate afterCompletion processing should be deferred until an explicit call for it is made, as they currently bundle it in automatically and must continue to do so in the default JCA case.
I like solution #2 for now (single sync in the parent), for speed and simplicity (it is more or less what I have already planned on doing); adding functionality for propagating calls up the chain can add a lot of complexity (thus risk given the short timeframe) for us. If later on we discover we need two phases, then moving to #1 later on should be not be a problem, though it could add significant latency.
The only thing I'd be concerned about is the extra work that you'd have to do for exposing this hook, but it shouldn't block us as long as it appears sometime before the EAP final release (we can just mark the source with comments at the appropriate location; we should be able to test most functionality without it).
This is what I was attempting to describe above. That said, the limitation with this approach is clear, in the case where there are no synchronizations registered on the subordinate TM, we will still have to call each subordinate TM with a beforeCompletion message as the root TM will not be aware of which subordinates do/don't have sync's registered, a perfomance penalty.
Yeah, I'm okay with that. Later on perhaps we can find a way to optimize that away.