[infinispan-dev] Atomic operations and transactions

[Galder Zamarreño]

On Jul 5, 2011, at 1:24 PM, Dan Berindei wrote:

> On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> 2011/7/5 Dan Berindei <dan.berindei at gmail.com>:
>>> Here is a contrived example:
>>> 
>>> 1. Start tx Tx1
>>> 2. cache.get("k") -> "v0"
>>> 3. cache.replace("k", "v0", "v1")
>>> 4. gache.get("k") -> ??
>>> 
>>> With repeatable read and suspend/resume around atomic operations, I
>>> believe operation 4 would return "v0", and that would be very
>>> surprising for a new user.
>>> So I'd rather require explicit suspend/resume calls to make sure
>>> anyone who uses atomic operations in a transaction understands what
>>> results he's going to get.
>> 
>> The problem is that as a use case it makes no sense to use an atomic
>> operation without evaluating the return value.
>> so 3) should actually read like
>> 
>> 3. boolean done = cache.replace("k", "v0", "v1")
>> and based on this value, the application would branch in some way, and
>> so acquiring locks and waiting for each other is not enough, we can
>> only support this if write skew checks are enabled, and mandate the
>> full operation to rollback in the end. That might be one option, but I
>> really don't like to make it likely to rollback transactions, I'd
>> prefer to have an alternative like a new flag which enforces a "fresh
>> read" skipping the repeatable read guarantees. Of course this wouldn't
>> work if we're not actually sending the operations to the key owners,
>> so suspending the transaction is a much nicer approach from the user
>> perspective. Though I agree this behaviour should be selectable.
>> 
> 
> Ok, I'm slowly remembering your arguments... do you think the "fresh
> read" flag should be available for all operations, or does it make
> sense to make it an internal flag that only the atomic operations will
> use?
> 
> To summarize, with this example:
> 1. Start tx
> 2. cache.get("k") -> "v0"
> 3. cache.replace("k", "v0", "v1")
> 4. gache.get("k") -> ??
> 5. Commit tx
> 
> The options we could support are:
> a. Tx suspend: no retries, but also no rollback for replace() and 4)
> will not see the updated value

Right, this is what I trying to get to= earlier. If you went for the tx suspend option (particularly if this is done under the hood), this would certainly different behaviour to 4.x and looks quite dangerous TBH. However, this type of scenarios can be protected against from within the Infinispan.

> b. Optimistic locking + write skew check: if the key is modified by
> another tx between 2) and 5), the entire transaction has to be redone
> c. Optimistic locking + write skew check + fresh read: we only have to
> redo the tx if the key is modified by another tx between 3) and 5)

Infinispan can keep track of read keys and so it can use the fresh read option on an atomic operation if the key has been read previously in the transaction. So, these two options could be merged into 1 IMO.

> d. Pessimistic locking: if the key is modified between 2) and 5), the
> entire transaction has to be redone
> e. Pessimistic locking + fresh read: no redo, but decreased throughput
> because we hold the lock between 3) and 5)
> 
> I guess there is no reason to support option d), as we're making an
> RPC to the owner in order to get the lock anyway.

Yeah, d) does not make sense cos if you go remote for a get("k"), you'd have to go remote for replace() too in order to be fully correct. A modification and L1 invalidation could have happened in an owner node for "k" in between 2) and 3)

> I think I'm leaning
> towards supporting only a) and e), but there might be cases where b)
> and c) would perform better.

Thanks for compiling these options. 

So, my preference is for a), combined b+c) and e).

With http://community.jboss.org/docs/DOC-16973 in mind, it'd only be a) that would need adding. b+c) would be covered by the global OL/hybrid config and e) would be PL.

> 
> Dan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache