Re: [infinispan-dev] on optimistic locking semnatics
Hi,
On 22 Jun 2012, at 15:47, Mircea Markus wrote:
I've come around a JIRA[1] about optimistic locking and write
skew check, and wondering what's the expected behavior in the following scenario:
tx1.begin()
read(a);
// tx2 modifies 'a' and commits changes
write(b);
tx1.commit() - shall I get a write skew (version changed) exception here as a was
modified between read and commit?
Yes! Your scenario is an example of a write skew [2].
In other words, shall I also perform write skew check for the entries
that were read during a tx? We currently don't, but I can totally see situations in
which this would be needed: if the decision to write to 'b' is made on the value
of 'a' and there's an invariant containing both a and b.
I would expect that a configuration named writeSkewCheck, when set to "true",
did exactly that kind of check, yes.
I've actually been assuming that this was already implemented, as I've been using
writeSkewCheck="true" in Infinispan's configuration to ensure that my
applications present a consistent transactional behaviour.
[2] Here's some more useful info on this topic:
"A read-only transaction anomaly under snapshot isolation":
http://dl.acm.org/citation.cfm?id=1031573
"Making snapshot isolation serializable":
http://dl.acm.org/citation.cfm?id=1071615
Cheers,
--
Sérgio Miguel Fernandes