[jboss-dev-forums] [JBoss Transactions Development] - Re: Remote Txn Inflow: Synchronizations

[David Lloyd]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion

"Re: Remote Txn Inflow: Synchronizations"

To view the discussion, visit: http://community.jboss.org/message/629888#629888

--------------------------------------------------------------
> Tom Jenkinson wrote:
> 
> > David Lloyd wrote:
> > 
> > > Tom Jenkinson wrote:
> > > 
> > > > Jonathan Halliday wrote:
> > > > 
> > > > It's hard to do lazily when all the communication is top down - there is no mechanism for the child to call up to the parent to register. 
> > > This is what I was thinking also. Without having some way to expose the transaction managers as network endpoints (and the work within ArjunaJTA to make it possible to talk to them), as Jonathan says I think we are at the mercy of top-down approach and the workarounds that approach needs.
> > We'd need to probably come up with some clever way to modify recovery processing, I can't think of any other way to solve this.
> > 
> > Are we sure that we need afterCompletion synchronization processing to be executed in terms of the root controller?  The only time I can imagine it mattering is if it is controlling some resource that is outside of the JVM, outside of the transaction, and yet visible to other participants.  If synchronizations are used for the purpose of discovering the overall outcome of the transaction, then executing on the local node achieves that purpose.  Same thing if the purpose is to clean up some per-VM resource.  And I think these two use cases are by far the predominant ones.
> > 
> > I would argue that it is actually more effective to define the behavior in terms of the single VM.  Especially considering that no other solution seems to be forthcoming...
> > 
> > For our purposes, it might be best to come out and specify that afterCompletion only runs in terms of the individual VM's view of the overall transaction.  Then later on we can revisit having this behavior be configurable, if we actually find a good solution for how to perform this recovery.
> > 
> > I know it's probably not an ideal solution, but I think it will cover 95% of the use cases correctly, and I suspect that the last 5% ought to be using proper XAResources of their own.
> From reading your message, I have understood your requirement to be the following:
> 
> Cascade beforeCompletion to subordinate TMs
> Cascade prepare
> Cascade commit/rollback (triggering afterCompletions locally)
> 
> i.e. do not factor out afterCompletions to a separate cascade. In that case, it is possible to get afterCompletions firing in the scenario where the transaction fails to complete correctly (i.e some XAR made a heuristic descision).
That is correct.  However I argue that because of the non-durability of afterCompletions, this is no worse than the existing situation - anyone who relies on afterCompletion for the correctness of their transaction is subject to data loss if the VM crashes after the transaction is committed but before afteCompletion runs.  Because of this, as far as I see it, the only correct usage of afterCompletion is cleaning up local resources that don't survive a VM crash.  I just doesn't seem like a big loss to me.
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/629888#629888]

Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2041]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20111003/80f9eb1d/attachment.html