Thanks. Well, the User Guide must detail the API and focus on general usage. We don't want to scare users with internal details that are more useful in a Developer Guide or Integrator Guide. So we must find the right balance for what info we supply in the User Guide.
Vlad On Mon, Jan 25, 2016 at 1:46 PM, Radim Vansa <rva...@redhat.com> wrote: > I wish the docs were as descriptive as your blog - thanks Vlad! (so, I > should make that happen). > > So I (hopefully) finally understand what you mean by sync/async: > * sync implements only certain methods from the *RegionAccessStrategy and > the two-phase commit requires TM calling 2LC directly (either by > registering itself as XAResource or Synchronization) > * async implements all methods and does not need to interact with TM at > all. > > However, this is just an implementation detail which should not relate to > cache concurrency strategy, should it? CCS should define only the isolation > level achieved, and that is: > * nonstrict-read-write: read committed with short window for stale reads > during commit > * read-write: read committed > * transactional: serializable > > Radim > > On 01/25/2016 11:55 AM, Vlad Mihalcea wrote: > >> 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 <mailto: >> 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> >> > <mailto: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>> >> > > <mailto: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 <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
