[infinispan-dev] What should be the default transaction mode: transactional or non-transactional?

[Manik Surtani]

Don't transactional caches require a JTA cache manager being present, configured and running?

On 28 Sep 2011, at 17:10, Mircea Markus wrote:

> Hi,
> 
> ATM the default cache transaction model in 5.1 is transactional. The main reason transactional cache was chosen by default was backward compatibility: existing code that access the cache in a mixed way (i.e. both transactional and non transactional) would fail if the default mode is non transactional. By fail I don't mean a runtime exception being thrown, but the the operations in transaction's scope being executed individually and the transaction ignored.
> 
> As Galder highlighted, the problem with being transactional by default is that you pay a penalti if you take Infinispan and run out of the box as a simple local cache for example. In theory, in only makes sense to enable transactional behaivour if you want transactions. [1]
>  
> Shall we switch to non-tx caches by default? Or implement ISPN-61 in 5.1, measure performance and if perf is ok stick with transactional cache? [2] Opinions?
> 
> Cheers,
> Mircea
> 
> 
> [1]
> a). The performance for a get should be the same for a tx and non tx cache. 
> b)  Put's performance is better now: 1RPC for non-tx and 2 RPC for tx. However this will change once https://issues.jboss.org/browse/ISPN-61. With ISPN-61 implemented, I expect the performance of both tx and non-tx caches to be roughly the same.
> 
> [2] Implementing first optimisation described in ISPN-61 is rather trivial right now.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110928/2647a1af/attachment-0001.html