Thanks for correcting the terms, I'll try to use 'isolation'. TX2 reading B = 1 is not READ_UNCOMMITTED - value B = 1 was committed long ago (it's the initial value). It's reading A = 2 what can be considered read uncommitted (not isolated enough), but as the cache has nothing to do with that entry, we can't really prevent it - it's already in the DB. So it's really rather a stale read of B. If my terms I wrong, I apologize.
"as close together as possible" is not enough - either you allow certain situation to happen (although you might try to minimize how often), or you guarantee that it does not happen. So, do I understand it correctly that 2LC should check ' hibernate.connection.isolation' and behave accordingly? In 2LC code I am sometimes registering synchronizations but always through SessionImplementor.getTransactionCoordinator() .getLocalSynchronizations().registerSynchronization(...) - I hope this is the right way and not asking for trouble. I usually just need to do something when I know whether the DB has written the data or not - Hibernate calls the *AccessStrategy methods well enough in the beforeCompletion part (or I should rather say during flush()) but sometimes I need to delegate some work to the afterCompletion part. Radim On 09/09/2015 04:51 PM, Steve Ebersole wrote: > 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 <rva...@redhat.com > <mailto:rva...@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 <rva...@redhat.com <mailto:rva...@redhat.com>> > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev