[infinispan-dev] rethinking ISPN transactions

[Mircea Markus]

On Dec 3, 2013, at 1:28 PM, Mark Little <mlittle at redhat.com> wrote:

> 
> On 29 Nov 2013, at 15:54, Mircea Markus wrote:
> 
>> 
>> On Nov 29, 2013, at 1:45 PM, Mark Little <mlittle at redhat.com> wrote:
>> 
>>> I haven't looked at how ISPN does this today, but here are some thoughts given how we do this within the transaction system for ACID transactions:
>>> 
>>> (i) have you considered async prepare?
>> 
>> There is a certain degree of asynchronicity in the sense that the prepare we send happens in parallel on all the nodes involved in the transaction. Is this what you have in mind? 
> 
> With async prepare you send each prepare request asynchronously (!) and then wait for responses, rather than send each prepare and wait for a response before moving on to the next prepare request.

That is exactly what we do.

> 
>> 
>>> 
>>> (ii) async commit/rollback could involve an external audit component to capture the outcome of the transaction, which can be inspected later. Many years ago the OTS and CORBA Notification Service did this together.
>> 
>> If the commit/rollback fails this should be picked up by the TM recovery process - I guess that would do the job. 
>> This improves the throughput indeed, but might be confusing for users: reading the data written by a "successfully" completed transaction (i.e. TM.commit() returns without exception) would not work.
> 
> Data cannot be read until the transaction has completed (one way or another). So I'm not sure what the problem is you're alluding to here.


store.put(k,v1); //initial value
tm.begin()
store.put(k,v2);
tm.commit();

assert store.get(k).equals(v2); //this might fail with async commits, which for some users would be surprising

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)