The docs are in a state of flux for 5.1. For now your best bet is the source: documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> wrote: Hi, I was about to fill some gaps in 2LC docs regarding improvements in 5.0/5.1, but when I took a look into 5.0 docs [1] there's close to nothing; is it by purpose? In 4.3 docs [2], there's much more on this subject. Am I looking in a wrong place? Radim [1] http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching [2] http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#perform... -- Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi Radim, I'm now filling in the missing sections on the Caching chapter in the 5.1 User Guide. Vlad On Wed, Jan 20, 2016 at 11:32 AM, Radim Vansa <rvansa(a)redhat.com&gt; wrote: > I would say that the best source is 4.x docs, since the cited source is > what I describe by 'close to nothing'. > > I understand that for 5.1 the transformation might be unfinished, but I > was surprised by the same for 5.0 - missing information that's written, > maybe just not formatted properly for asciiidoc. In such case, link to > appropriate chapter in older docs would be useful. > > Radim > > On 01/19/2016 07:04 PM, Steve Ebersole wrote: > > The docs are in a state of flux for 5.1. For now your best bet is the > > source: > documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc > > > > On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa <rvansa(a)redhat.com > > <mailto:rvansa@redhat.com>> wrote: > > > > Hi, > > > > I was about to fill some gaps in 2LC docs regarding improvements in > > 5.0/5.1, but when I took a look into 5.0 docs [1] there's close to > > nothing; is it by purpose? In 4.3 docs [2], there's much more on > this > > subject. Am I looking in a wrong place? > > > > Radim > > > > [1] > > > http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching > > [2] > > > http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#perform... > > > > -- > > Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > > JBoss Performance Team > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > -- > Radim Vansa <rvansa(a)redhat.com&gt; > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

Seems much more comprehensive, though I can't find e.g. 'Cache-provider/concurrency-strategy compatibility' table (already out-of-date). Nevertheless, thanks! I'll try to find some timeslot for updating it early next week. Radim On 01/21/2016 04:17 PM, Vlad Mihalcea wrote: > Hi Radim, > > I've just committed the updated version of the Caching chapter. > To build it, you need to: > > 1. go to the documentation folder > 2. run gradle rUG > 3. The new user guide is located under: > documentation/target/asciidoc/userguide/html/Hibernate_User_Guide.html > > Let me know what you think. > > Vlad > > On Wed, Jan 20, 2016 at 11:57 AM, Vlad Mihalcea > <mihalcea.vlad(a)gmail.com <mailto:mihalcea.vlad@gmail.com>> wrote: > > Hi Radim, > > I'm now filling in the missing sections on the Caching chapter in > the 5.1 User Guide. > > Vlad > > On Wed, Jan 20, 2016 at 11:32 AM, Radim Vansa <rvansa(a)redhat.com > <mailto:rvansa@redhat.com>> wrote: > > I would say that the best source is 4.x docs, since the cited > source is > what I describe by 'close to nothing'. > > I understand that for 5.1 the transformation might be > unfinished, but I > was surprised by the same for 5.0 - missing information that's > written, > maybe just not formatted properly for asciiidoc. In such case, > link to > appropriate chapter in older docs would be useful. > > Radim > > On 01/19/2016 07:04 PM, Steve Ebersole wrote: > > The docs are in a state of flux for 5.1. For now your best > bet is the > > source: > documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc > > > > On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa > <rvansa(a)redhat.com <mailto:rvansa@redhat.com> > > <mailto:rvansa@redhat.com <mailto:rvansa@redhat.com>>> wrote: > > > > Hi, > > > > I was about to fill some gaps in 2LC docs regarding > improvements in > > 5.0/5.1, but when I took a look into 5.0 docs [1] > there's close to > > nothing; is it by purpose? In 4.3 docs [2], there's much > more on this > > subject. Am I looking in a wrong place? > > > > Radim > > > > [1] > > > http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching > > [2] > > > http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#perform... > > > > -- > > Radim Vansa <rvansa(a)redhat.com > <mailto:rvansa@redhat.com> <mailto:rvansa@redhat.com > <mailto:rvansa@redhat.com>>> > > JBoss Performance Team > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > <mailto:hibernate-dev@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > -- > Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >

On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rvansa(a)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.

Could this wording be cleaned up? For sure. Feel free to make some suggested edits

I also don't really see what's the meaning of 'underlying cache implementation supports locking' - IMO it's implementation detail how the application achieves required level of consistency. The 'locking' term itself is a bit vague. No idea what that is supposed to mean. I did not write that, but I would guess the intent is to say that the being conveyed is that of consistency across the nodes of the cluster. 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.

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

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.

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_writ... http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cachecon... For sync: TRANSACTIONAL http://vladmihalcea.com/2015/06/01/how-does-hibernate-transactional-cache... 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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> wrote: On 01/22/2016 05:26 PM, Steve Ebersole wrote: > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com> > <mailto:rvansa@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>> > > <mailto:rvansa@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. 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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <rvansa(a)redhat.com&gt; 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_writ... >> >> http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cachecon... >> >> For sync: TRANSACTIONAL >> >> >> http://vladmihalcea.com/2015/06/01/how-does-hibernate-transactional-cache... >> >> 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 <rvansa(a)redhat.com >> <mailto:rvansa@redhat.com>> wrote: >> >> On 01/22/2016 05:26 PM, Steve Ebersole wrote: >> > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa(a)redhat.com >> <mailto:rvansa@redhat.com> >> > <mailto:rvansa@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>> >> > > <mailto:rvansa@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. >> >> 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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> >> JBoss Performance Team >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > > -- > Radim Vansa <rvansa(a)redhat.com&gt; > JBoss Performance Team > >