On 01/25/2016 11:48 AM, Radim Vansa 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.
So it seems that Infinispan handles repeatable reads of null correctly. > >> >> > 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