7:05 p.m.
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/o...
[2]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
--
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo
1:11 p.m.
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/o...
[2]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
--
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
2:49 p.m.
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/o...
>
> [2]
>
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
>
> --
> INESC-ID Lisboa, sala 511
> gsd.inesc-id.pt/~pruivo
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo
1:15 p.m.
Pedro,
The write skew check is only really supported for non-distributed cases at the moment. As
you can tell, it uses object references ("pointers") to compare whether the
value has changed and then throw an exception if the write skew check is enabled. As
such, this scheme makes no sense in a distributed sense.
One approach to enable write skews in clustered mode would be to use vector clocks as
entry versions. This could then be sent to a caller when a value is read, and
subsequently, when written, can be passed back to the owner as a part of a commit message.
The write skew check can then be made on the vector clock which will be able to detect
concurrent updates from elsewhere in the cluster.
Cheers
Manik
On 13 Jun 2011, at 18:05, 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/o...
[2]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
--
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
4967
days inactive
4968
days old
infinispan-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
Galder Zamarreño -
Manik Surtani -
Pedro Ruivo