+1. I think we need to generally understand a user guide and an integration guide. Very different audiences.
On Mon, Jan 25, 2016 at 6:22 AM Vlad Mihalcea <mihalcea.v...@gmail.com> wrote: > 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
