[hibernate-dev] Consistency guarantees of second level cache

[Steve Ebersole]

To be precise when you talk the stale data you are really asking about
isolation.  TX2 reading "B->1" before TX1 commits is a question of
isolation and preventing READ_UNCOMMITTED access to the data.  The problem
is the split in the notion of "commit".  Those should be "as close together
as possible".  For what it is worth, Hibernate commits its work via
Synchronization as well.  My preference (and this is based on years of
fighting problems specifically between Hibernate and
TreeCache/JBossCache/Infinispan in regards to Synchronization ordering) is
that hibernate-infinispan piggyback on Hibernate's transaction handling.
Actually, I thought this is why we made some of the transaction changes we
did in Hibernate.. so that you could have a consistent view of the
transaction across jdbc/jta in hibernate-infinispan.  In my experience,
having hibernate-infinispan/Infinispan register its own Synchronization to
control this stuff is just asking for a lot of trouble.

Anyway, this also gets into the meaning of the concurrent access
strategies.  Which access strategy are you talking about in particular?  I
assume you mean the `transactional` strategy, just making sure.




On Wed, Sep 9, 2015 at 6:58 AM Radim Vansa <rvansa at redhat.com> wrote:

> 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
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>