[infinispan-dev] Some flags are incompatible with implicit transactions

Mircea Markus mircea.markus at jboss.com
Wed Dec 14 09:05:38 EST 2011


On 14 Dec 2011, at 15:55, Galder Zamarreño wrote:

> 
> On Dec 14, 2011, at 2:45 PM, Mircea Markus wrote:
> 
>> 
>> On 13 Dec 2011, at 16:00, Sanne Grinovero wrote:
>> 
>>> On 13 December 2011 13:48, Galder Zamarreño <galder at redhat.com> wrote:
>>>> 
>>>> On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
>>>> 
>>>>> Why would you avoid FORCE_WRITE_LOCK ?
>>>> 
>>>> Does the following make sense?
>>>> 
>>>> tx.begin()
>>>> cache.withFlags(FORCE_WRITE_LOCK).get(…)
>>>> tx.commit()
>>> 
>>> Yeah it's pointless to use locks if you have a single operation, but I
>>> might want to do more operations in a single transaction.. actually
>>> what's the point of using a transaction if I have only one operation?
>> WIthout transaction it is possible that the operation is only partially applied, i.e. on a subset of numOwners, resulting in inconsistent state.
> 
> Good point Mircea. You should definitely document that cos that's pretty much the sole reason to use implicit transactions, something users should know.
Nope. The reason the induced transactions(autoCommit) were added is backward compatibility: prev infinispan versions allowed mixed cache access: i.e. both transactional and non-transactional calls to a cache. Starting with 5.1,  an exception is thrown if a cache method is invoked outside of a tx's context,  unless autoCommit is set to true.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20111214/988ce1bb/attachment.html 


More information about the infinispan-dev mailing list