-
1. Re: MVCC Write Skew
manik Apr 6, 2009 5:45 AM (in response to zeravlai)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) -
2. Re: MVCC Write Skew
zeravlai Apr 6, 2009 7:52 AM (in response to 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). -
3. Re: MVCC Write Skew
manik Apr 6, 2009 12:08 PM (in response to zeravlai)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. -
4. Re: MVCC Write Skew
zeravlai Apr 7, 2009 5:10 AM (in response to 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 ?? -
5. Re: MVCC Write Skew
zeravlai Apr 8, 2009 1:39 PM (in response to 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 ?? -
6. Re: MVCC Write Skew
manik Apr 8, 2009 6:34 PM (in response to zeravlai)"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. :-) -
7. Re: MVCC Write Skew
zeravlai Apr 8, 2009 7:37 PM (in response to 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 !! -
8. Re: MVCC Write Skew
manik Apr 9, 2009 7:36 AM (in response to zeravlai):-) Apart from lock acquisition timeouts and data versioning exceptions, that's really it. These could happen both locally and remotely, of course.