[infinispan-dev] Atomic operations and transactions

[Mircea Markus]

On 30 Jun 2011, at 14:11, Sanne Grinovero wrote:

> Hello all,
> some team members had a meeting yesterday, one of the discussed
> subjects was about using atomic operations (putIfAbsent, etc..).
> Mircea just summarised it in the following proposal:
> 
> The atomic operations, as defined by the ConcurrentHashMap, don't fit
> well within the scope of optimistic transaction: this is because there
> is a discrepancy between the value returned by the operation and the
> value and the fact that the operation is applied or not:
> E.g. putIfAbsent(k, v) might return true as there's no entry for k in
> the scope of the current transaction, but in fact there might be a
> value committed by another transaction, hidden by the fact we're
> running in repeatable read mode.
> Later on, at prepare time when the same operation is applied on the
> node that actually holds k, it might not succeed as another
> transaction has updated k in between, but the return value of the
> method was already evaluated long before this point.
> In order to solve this problem, if an atomic operations happens within
> the scope of a transaction, Infinispan eagerly acquires a lock on the
> remote node. This locks is held for the entire duration of the
> transaction, and is an expensive lock as it involves an RPC. If
> keeping the lock remotely for potentially long time represents a
> problem, the user can suspend the running transaction and run the
> atomic operation out of transaction's scope, then resume the
> transaction.
Just to make this clearer, optimistic locking is what we'll get my only acquiring locks at prepare time:http://community.jboss.org/wiki/OptimisticLockingInInfinispan 
> 
> 
> In addition to this, would would you think about adding a flag to
> these methods which acts as suspending the transaction just before and
> resuming it right after? I don't know what is the cost of suspending &
> resuming a transaction,
I'd expect it to be no more than a remove from a ThreadLocal.
> but such a flag could optionally be optimized
> in future by just ignoring the current transaction instead of really
> suspending it, or apply other clever tricks we might come across.
The only reason I see for such a flag is to make the code easier to write. AFAIK you're the only user for this functionality ATM, so if it makes your life easier, i.e. it makes you write considerably fewer lines of code then +1.
OTOH if it's only few places where you make use of it, then I'd rather not add it now - but only in future when there's more demand for this functionality.   
> 
> I also think that we should discuss if such a behaviour should not be
> the default - anybody using an atomic operation is going to make some
> assumptions which are clearly incompatible with the transaction,
The behaviour I described, whilst costly, is not incompatible with the transaction, so should not cause any surprise.
> so
> I'm wondering what is the path here to "least surprise" for default
> invocation.

> 
> Regards,
> Sanne
> _______________________________________________
> 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/20110630/c597a767/attachment.html