Re: [hibernate-dev] 2LC docs

On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> wrote: On 01/22/2016 03:11 PM, Steve Ebersole wrote: > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com> > <mailto:rvansa@redhat.com <mailto:rvansa@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.

> 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.