Hi, I have some sequence diagrams depicting the async/sync behavior if you are interested:
For async: NONSTREICT_READ_WRITE and READ_WRITE: http://vladmihalcea.com/2015/05/18/how-does-hibernate-nonstrict_read_write-cacheconcurrencystrategy-work/ http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ For sync: TRANSACTIONAL http://vladmihalcea.com/2015/06/01/how-does-hibernate-transactional-cacheconcurrencystrategy-work/ Only the region strategy differs since it's not Ehcache, but everything else is from Hibernate API. Vlad On Mon, Jan 25, 2016 at 12:48 PM, Radim Vansa <rva...@redhat.com> wrote: > On 01/22/2016 05:26 PM, Steve Ebersole wrote: > > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rva...@redhat.com > > <mailto:rva...@redhat.com>> wrote: > > > > On 01/22/2016 03:11 PM, Steve Ebersole wrote: > > > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rva...@redhat.com > > <mailto:rva...@redhat.com> > > > <mailto:rva...@redhat.com <mailto:rva...@redhat.com>>> wrote: > > > > > > Why should the strategy 'never be used if serializable > > transaction > > > isolation level is required'? What guarantees it gives, and > what > > > in ORM > > > core depends on this? When I've asked the last time, Steve > said > > > that all modes but the > > > > > > nonstrict one require that the 2LC is absolutely transparent > > > (consistency-wise), so you always get the same answer as if > > you were > > > directly talking to DB. > > > > > > > > > I would guess this is talking about "serializable isolation" at the > > > application layer. Yes extended across both the application and > > > database. In our original implementations we had no L2 cache > > > providers that would support serializable isolation. Does > > > hibernate-infinispan? If we ask for a certain entry from the > > cache in > > > T1, T2 adds that entry and commits, and then we ask for it again > > in T1 > > > do we still see it as "not existing"? I'd highly doubt it, but > > if it > > > does then lets make note of that. > > > > No, without a transactional cache, it does not. Thanks for the > > example. > > But will the request get to 2LC, or will it be served already from > > Session cache? > > > > > > It won't work even with a transactional cache I believe. It won't work > > with Infinispan e.g. I do not think. Hibernate does not keep reference > > to "non-existing" entities. That's the only way the Session could > > "serve" the fact that the first T1 lookup found nothing. Again, this > > gets right back to that idea of consistency. Without L2 caching, in > > this scenario with serializable isolation the database would return me > > "no row" in both T1 SELECTs. > > Infinispan keeps 'transactional context' for the current transaction and > stores all reads there, even if this is a null read. However, as I've > checked the distribution code, it still does the remote lookup (which > escapes the transaction) and the value could get there even with > so-called repeatable reads. I'll check infinispan-dev why. > > > > > > Does the ' you should ensure that the transaction is completed > when > > > `Session.close()` or `Session.disconnect()` is called' still > > hold, or > > > does the transactional rework in 5.0 somehow obsolete this > info? > > > > > > > > > I cannot say why this is discussed in a chapter on caching. > > > Session#disconnect is largely deprecated (its main use case is > > handled > > > much more transparently now). IMO it's always a good idea to make > > > sure a transaction against a resource is completed prior to closing > > > that transaction. That's no different for a Hibernate Session > > then it > > > is for a JDBC Connection, etc. > > > > Did you meant 'commit the transaction before closing the session'? If > > the Session.close() is called with tx open, will the transaction be > > committed? But any way, this should be really the same as without > 2LC. > > > > > > I meant to say " make sure a transaction against a resource is > > completed prior to closing that resource". Saying "complete the > > transaction" != "commit the transaction". Completion might be either > > commit or rollback. But the idea is that it is in a definitive state. > > > > Historically what a stranded transaction at the time of Session#close > > meant depended on the JDBC driver. Most drivers rollback back on a > > stranded transaction; Oracle has always been the notable exception as > > they would commit a stranded transaction. But regardless in terms of > > Session locks etc in the cache that would strand the locks as well iirc. > > > > In developing 5.0 and the new transaction handling I know we talked > > about making this more deterministic, specifically always handling > > this as if a rollback had been called. But to be honest, that's not > > what I am seeing in the code. Andrea, do you remember? If not, we > > should definitely add some tests for this to see what happens atm and > > make sure its really what we want to have happen moving forward. > > > > > > > Basically this passage is a poorly worded hint. What it is > > trying to > > > convey is that for "asynchronous" cache access what drives the > > > interactions with the Cache is the Hibernate transaction, and in > > these > > > case the user should take extra care to make sure that the > > transaction > > > is handled properly. That still holds true. > > > > > > As a refresher, the idea of "synchronous" versus "asynchronous" is > > > simply cache access that is driven by JTA ("synchronous") versus > > those > > > that are driven by local transactions ("asynchronous"). > > > > > > Eh, I probably don't get the exact meaning of 'driving the access' > :-/ > > And I can't find any reference to 'async' in user guide. > > > > > > I keep pointing y'all to > > org.hibernate.cache.spi.access.EntityRegionAccessStrategy, > > org.hibernate.cache.spi.access.CollectionRegionAccessStrategy, etc as > > the best source for this information. I spent a lot of time > > documenting (javadoc) these contracts as I developed them. > > sync/async is discussed there. No need for it to be discussed in the > > user guide IMO, its a concept for developers of cache implementations > > to understand not users. > > Okay, this sync/async. Sure, then it makes sense that it's not in user > guide. But pardon my confusion, that class documents which methods are > used by sync/async strategies, and what's the order of method > invocation, but I never got what is the idea behind the sync/async > strategy differentiation. As I've started messing with ORM only after > the 5.0 tx rework, I always considered the difference between JTA and > local transactions just an implementation detail orthogonal to 2LC. > > Radim > > -- > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
