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

[Mircea Markus]

2 use cases:

 - existing users already have this in place
-  non exiting users: defaults to DummyTM.

On 28 Sep 2011, at 17:44, Manik Surtani wrote:

> 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
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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