On Tue, May 25, 2010 at 02:00:42PM +0200, Nicolas Barbier wrote:
> I don't understand the problem. According to me, in the context of
> SSI, a read-only slave can just map SERIALIZABLE to the technical
> implementation of REPEATABLE READ (i.e., the currently-existing
> "SERIALIZABLE"). The union of the transactions on the master and the
> slave(s) will still exhibit SERIALIZABLE behavior because the
> transactions on the slave cannot write anything and are therefore
> irrelevant.
This, unfortunately, isn't true in SSI.
Consider read-only transactions on a single node SSI database -- the
situation is the same for read-only transactions that run on a slave.
These transactions can be part of anomalies, so they need to be checked
for conflicts and potentially aborted.
Consider Kevin's favorite example, where one table contains the current
date and the other is a list of receipts (initially empty). T1 inserts (select current_date) into receipts, but
doesn'tcommit T2 increments current_date and commits T3 reads both current_date and the receipt table T1 commits
T3, which is a read-only transaction, sees the incremented date and an
empty list of receipts. But T1 later commits a new entry in the
receipts table with the old date. No serializable ordering allows this.
However, if T3 hadn't performed its read, there'd be no problem; we'd
just serialize T1 before T2 and no one would be the wiser.
SSI would detect a potential conflict here, which we could resolve by
aborting T3. (We could also abort T1, but if this is a replicated
system this isn't always an option -- T3 might be running on the
slave, so only the slave will know about the conflict, and it can't
very well abort an update transaction on the master.)
There's another example of a read-only transaction anomaly that could
cause similar problems at
http://portal.acm.org/citation.cfm?doid=1031570.1031573, but I think
this one is easier to follow.
Dan
--
Dan R. K. Ports MIT CSAIL http://drkp.net/
