[infinispan-dev] commit not failing but transaction reported as in-doubt

Mircea Markus mmarkus at redhat.com
Wed May 15 10:06:03 EDT 2013


Thanks again for nice explanation Jonathan!
@Pedro - seems like you're doing the right thing by encouraging people to be properly paranoid :-)
Otherwise we'd leak tx logs (in infinispan parlance the PrepareCommands in the recovery cache) which would not be nice. 

On 15 May 2013, at 13:32, Jonathan Halliday <jonathan.halliday at redhat.com> wrote:

> 
> No, it's out of scope for the TM, at least as far as the JTA/XA specs 
> are concerned. The TM would not retain any txlog information to allow it 
> to perform useful recovery anyhow.   Usually you just log it in the hope 
> a human notices and sorts out the mess.  Of course properly paranoid 
> humans don't use async commit in the first place.
> 
> There has been various talk around making JTA TM.commit() support an 
> async callback, such that the business logic thread can continue as soon 
> as the prepare phase is successful, whilst still receiving a callback 
> handler invocation if the commit phase subsequently fails. Extending 
> that to the XA protocol would be nice, but won't happen as there is no 
> upward (RM->TM) communication in XA - it's all driven top down.  So as 
> you point out, adding the failed tx to the in-doubt list is the only way 
> of signalling a problem. That's bad, since you'd also need a positive 
> 'it worked' callback in the proto to allow GC of the txlog, otherwise 
> you have to throw away the log eagerly and can't then do anything useful 
> with the subsequent error callback anyhow.
> 
> Associated with that discussion is the expectation around the semantics 
> of afterCompletion, which may mean 'after successful prepare' or 'after 
> successful commit' in such case, the latter effectively removing the 
> need for a new JTA callback api in the first place.
> 
> If you don't need a callback at all, then there is already an async 
> commit option in the TM config, it's just non-standard and marginally 
> dangerous. It simply logs commit phase failures and hopes a human notices.
> 
> Jonathan.
> 
> On 05/15/2013 01:13 PM, Mircea Markus wrote:
>> Hi Jonathan,
>> 
>> In the scope of ISPN-3063 [1] we came to a problem we need some advice on :-)
>> 
>> Would a transaction manager expect/handle this situation: for a transaction the commit is successful but at a further point the same transaction would be reported as "in-doubt" to the recovery process. In our case this can happen when we send the commit async and this might only fail after the commit is acknowledged to the TM.
>> 
>> [1] https://issues.jboss.org/browse/ISPN-3063
>> 
>> Cheers,
>> 
> 
> -- 
> Registered in England and Wales under Company Registration No. 03798903 
> Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
> (USA), Charlie Peters (USA)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list