[infinispan-dev] Write skew check implementation

[Pedro Ruivo]

Hi,

Yes I meant distributed mode.

The scenario is this:

N1 owns the key d. N2 executes a transaction that read d and then write 
it. When it needs to read, it gets the value from N1. On commit phase, 
N2 sends the prepare message with the new value of d.

The problem I was exposing is that the value of d can change, on N1, 
between the read and the prepare message, and the transaction in N2 can 
commit anyway.

The definition of write skew is: "When write skew check is set to false, 
if the writer at commit time discovers that the working entry and the 
underlying entry have different versions, the working entry will 
overwrite the underlying entry. If true, such version conflict - known 
as a write-skew - will throw an Exception". The behaviour above is 
different from definition.

Manik has already answered my question.

Thank you both.

Cheers,
Pedro

On 14-06-2011 12:11, Galder Zamarreño wrote:
> Hi Pedro,
>
> I assume that by partial replication mode you meant distributed mode (using consistent hash algorithm)?
>
> Hmm, why should n2 send the value of d before writing? n1 is an owner of d, so n1 should have that value.
>
> I'm not sure I'm understanding your question correctly.
>
> Cheers,
>
> On Jun 13, 2011, at 7:05 PM, Pedro Ruivo wrote:
>
>> Hi,
>>
>> I am progressing with my implementation of total-order-based commit
>> protocol for the partial replication mode, and I would be grateful if
>> you could help me understanding how the write skew check is implemented
>> in ISPN.
>>
>> Assume the scenario in which a node, say n1, that owns a data item d
>> receives a prepare message for a transaction, say T, originated on
>> different replica n2.
>>
>> Of course write skew check is enabled.
>>
>> After n1 acquiring the lock on d, it should check whether the value of d
>> read during T's execution is still the most recently committed one.
>>
>> I may be missing something here, but looking at [1] (lines 160 to 168)
>> and [2] at copyForUpdate method, n1 is reading twice the value of d that
>> is locally stored (once in line 160([1]) to create the
>> RepeatableReadEntry and a second time in line 52([2]) to do the write
>> skew check).
>>
>> I would have expected that the node that originated the transaction
>> would send the values that it read (before writing them) in piggyback
>> with the prepare message, in order to allow the "owners" to perform the
>> write skew.
>>
>> Thanks
>>
>> Pedro
>>
>> [1]
>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactoryImpl.java
>>
>> [2]
>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/entries/RepeatableReadEntry.java
>>
>> -- 
>> INESC-ID Lisboa, sala 511
>> gsd.inesc-id.pt/~pruivo
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo