[infinispan-dev] rethinking ISPN transactions

Jonathan Halliday jonathan.halliday at redhat.com
Thu Nov 21 11:20:15 EST 2013


hmm. Synchronizations are for a fundamentally different use case to 
XAResources.  They exist for the case in which you have a write behind 
cache that requires flushing to a backing store, or a write through 
cache that must expose state on commit or discard state on rollback. The 
cache is a Synchronization, the backing store is an XAResource. 
infinispan as a single process Cache is a Synchronization, whilst 
infinispan as a data grid or distributed cache is an XAResource.

When used in the latter mode it does not require both a Synchronization 
and an XAResource, since the XAResource can incorporate the 
Synchronization behaviour.  But the reverse is not true - a 
Synchronization can't take the place of an XAResource, since you can't 
implement recoverability in that case.  Some users are ok with that 
sacrifice and happy to abuse the Synchronization approach to gain 
performance, but it's a hack that can end in tears if they don't fully 
understand the implications of the tradeoff.

You can reasonably remove support for using a Synchronization in cases 
where an XAResource is more appropriate.  I don't see how you can remove 
Synchronizations entirely and still allow infinispan to be used as a 
transaction aware cache, which seems rather important to e.g. hibernate.

Jonathan.

On 11/19/2013 04:01 PM, Dan Berindei wrote:
> Maybe synchronization support is another thing that we should scrap in
> 7.0, then?

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham (USA), Paul Hickey (Ireland), Matt Parson
(USA), Charlie Peters (USA)


More information about the infinispan-dev mailing list