MVCC Write Skew

[zeravlai]

I've been testing with MVCC in order to reproduce write skew. Testing's been done with JPA/Hibernate in this way:

1.- Two concurrent threads read a field of an entity.
2.- Both of them increment (by one) that field based on the value previously read.

Results are as expected. R_R causes a Data Versioning Exception and R_C does not produce any exception.

However, and this is my question, results with the two transactions are the same. Entity field is incremented one with R_R since one transaction rollbacks and same result is seen with R_C though without exception.

Is the behaviour of R_C correct ?

[manik]

Yes, since what is an increment to you (i++) is actually a set to the cache (e.g., set i = blah) where blah has been pre-calculated based on an old value read. So even if you have R_C, even though your tx is re-reading the field at the time of setting, your application is not.

Basically, with R_C, the 2 TXs would be doing this:

i = 10
tx1: set i to 11
tx2: set i to 11 (even though i already is 11)

[zeravlai]

Thanks for your explanation, Manik.

However I still don't clearly see why the write skew check is just done in the markForUpdate of the Repeatable Read Node and not in Read Committed.

In my opinion both isolation levels should be checking for the write skew (maybe I'm missing something).

[manik]

It is an internal detail that prevents such a check in R_C. That internal detail is that I maintain a direct reference to the cached state. So if it changes (by another tx) I do not know this.

Now with R_R, I do know this since I maintain a copy to the cached state. And I can check if my copy is still the same as what is cached, and this is how I can check for write skews.

This copying is necessary for R_R (to provide consistency) but it is not necessary for R_C (since you always want to read committed state anyway). Adding this layer of copying just for the sake of write skew detection is an unnecessary overhead since the copy never will be used for anything else.

[zeravlai]

Ok, understood the detail, Manik. One more thing,

apart from the DataVersioningException with R_R, is there any other way that a transaction could abort under MVCC ??

Question is because wikipedia MVCC reference (which is pointed in the JBC document), talks about transactions aborting and restarting. Is there such a case with your implementation of MVCC ??

[zeravlai]

Also Manik,

I've read this sentence in the "clustering guide draft":

It achieves this (readers that don't block writers, writers that fail-fast) by using data versioning and copying for concurrent writers. The theory is that readers continue reading shared state, while writers copy the shared state, increment a version id, and write that shared state back after verifying that the version is still valid (i.e., another concurrent writer has not changed this state first).

I guess it refers to R_R behaviour ( and not R_C ), but again, is there any other reason (tx concurrency) to abort a transaction or restart it ??

[manik]

"zeravlai" wrote:

apart from the DataVersioningException with R_R, is there any other way that a transaction could abort under MVCC ??

Question is because wikipedia MVCC reference (which is pointed in the JBC document), talks about transactions aborting and restarting. Is there such a case with your implementation of MVCC ??

The wikipedia article is purely to explain the concept of MVCC. The details are, naturally, quite different in JBC when compared to a relational database. :-)

Anyway, yes there are other reasons why a tx may fail, including timeout exceptions in acquiring locks, timeout exceptions in replicating calls to remote nodes (if using synchronous mode), any number of network/io exceptions, exceptions with a cache loader when writing state to a loader, out of memory exceptions, etc. Take your pick. :-)

[zeravlai]

Come on Manik ;-)

I was talking about errors because of concurrent transactions, as data versioning exception with R_R, or as the error mentioned in the clustering guide that I posted before !!

[manik]

:-) Apart from lock acquisition timeouts and data versioning exceptions, that's really it. These could happen both locally and remotely, of course.