[hibernate-dev] Consistency guarantees of second level cache

[Radim Vansa]

Hi,

I've been fixing a lot of consistency issues in Infinispan 2LC lately 
and also trying to improve performance. When reasoning about consistency 
guarantees I've usually assumed that we don't want to provide stale 
entries from the cache after the DB commits - that means, we have to 
invalidate them before the DB commit. This is a useful property if there 
are some application constraints on the data (e.g. that two entities 
have equal attributes). On the other hand, if we want the cache 
synchronized with DB only after the commit fully finishes, we could omit 
some pre-DB-commit RPCs and improve the performance a bit.

To illustrate the difference, imagine that we wouldn't require such 
atomicity of transactions: when we update the two entities in TX1 and 
one of them is cached and the other is not, in TX2 we could see updated 
value of the non-cached value but we could still hit cache for the other 
entity, seeing stale value, since TX1 has committed the DB but did not 
finish the commit yet on ORM side:

A = 1, B = 1
TX1: begin
TX1: (from flush) write A -> 2
TX1: (from flush) write B -> 2
TX1: DB (XA resource) commit
TX2: read A -> 2 (handled from DB)
TX2: read B -> 1 (cached entry)
TX1: cache commit (registered as synchronization) -> cache gets updated 
to B = 2
TX1 is completed, control flow returns to caller

Naturally, after TX1 returns from transaction commit, no stale values 
should be provided.

Since I don't have any deep experience with DBs (I assume that they 
behave really in the ACID way). I'd like to ask what are the guarantees 
that we want from 2LC, and if there's anything in the session caching 
that would loosen this ACIDity. I know we have the nonstrict-read-write 
mode (that could implement the less strict way), but I imagine this as 
something that breaks the contract a bit more, allowing even larger 
performance gains (going the best-effort way without any guarantees).

Thanks for your insight!

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team