[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