Re: [hibernate-dev] 2LC docs

[Steve Ebersole]

+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 
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  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 >> > wrote:
>>>
>>> On 01/22/2016 05:26 PM, Steve Ebersole wrote:
>>> > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa >> 
>>> > >> wrote:
>>> >
>>> > On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>>> > > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa
>>> 
>>> > >
>>> > > 
>>> >> > >
>>> > > 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.
>>>

Re: [hibernate-dev] 2LC docs

[Radim Vansa]

On 01/22/2016 05:26 PM, Steve Ebersole wrote:
> On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa  > wrote:
>
> On 01/22/2016 03:11 PM, Steve Ebersole wrote:
> > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa  
> > >> 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") 

Re: [hibernate-dev] 2LC docs

[Vlad Mihalcea]

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  wrote:

> On 01/22/2016 05:26 PM, Steve Ebersole wrote:
> > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa  > > wrote:
> >
> > On 01/22/2016 03:11 PM, Steve Ebersole wrote:
> > > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa  > 
> > > >> 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

Re: [hibernate-dev] 2LC docs

[Radim Vansa]

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 > > wrote:
>>
>> On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>> > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa > 
>> > >> 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 

Re: [hibernate-dev] 2LC docs

[Vlad Mihalcea]

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  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>> wrote:
>>
>> On 01/22/2016 05:26 PM, Steve Ebersole wrote:
>> > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa > 
>> > >> wrote:
>> >
>> > On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>> > > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa
>> 
>> > >
>> > > 
>> > > >
>> > > 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 

Re: [hibernate-dev] 2LC docs

[Radim Vansa]

I'd like to ask for some details on these (probably Steve):

read-write::
If the application needs to update data, a read-write cache might be 
appropriate.
This cache strategy should never be used if serializable transaction 
isolation level is required.
If the cache is used in a JTA environment, you must specify the 
`hibernate.transaction.jta.platform` property.
In other environments, you should ensure that the transaction is completed 
when `Session.close()` or `Session.disconnect()` is called.
If you want to use this strategy in a cluster, you should ensure that the 
underlying cache implementation supports locking.
nonstrict-read-write::
If the application only occasionally needs to update data
(e.g. if it is extremely unlikely that two transactions would try to update 
the same item simultaneously)
and strict transaction isolation is not required, a nonstrict-read-write 
cache might be appropriate.
If the cache is used in a JTA environment, you must specify the 
`hibernate.transaction.jta.platform` property.
In other environments, you should ensure that the transaction is completed 
when `Session.close()` or `Session.disconnect()` is called.


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

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?

Thanks

Radim

On 01/21/2016 04:34 PM, Radim Vansa wrote:
> 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
>> > 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 >  > 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
>>  
>>  > >> 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/#performance-cache
>>  >
>>  > --
>>  > Radim Vansa >   >  

Re: [hibernate-dev] 2LC docs

[Steve Ebersole]

On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa  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").
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 2LC docs

[Steve Ebersole]

On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa  wrote:

> On 01/22/2016 03:11 PM, Steve Ebersole wrote:
> > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa  > > 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.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 2LC docs

[Radim Vansa]

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 
> > 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  > 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
> 
> > >> 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/#performance-cache
> >
> > --
> > Radim Vansa    >>
> > JBoss Performance Team
> >
> >  ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> 
>  >
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
> --
> Radim Vansa >
> JBoss Performance Team
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>


-- 
Radim Vansa 
JBoss Performance Team

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 2LC docs

[Vlad Mihalcea]

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 
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  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 > > > 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/#performance-cache
>> >
>> > --
>> > Radim Vansa >
>> > JBoss Performance Team
>> >
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org > >
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>>
>>
>> --
>> Radim Vansa 
>> JBoss Performance Team
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 2LC docs

[Radim Vansa]

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  > 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/#performance-cache
>
> --
> Radim Vansa >
> JBoss Performance Team
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


-- 
Radim Vansa 
JBoss Performance Team

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 2LC docs

[Vlad Mihalcea]

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  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  > > 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/#performance-cache
> >
> > --
> > Radim Vansa >
> > JBoss Performance Team
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org 
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
> --
> Radim Vansa 
> JBoss Performance Team
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 2LC docs

[Steve Ebersole]

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  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/#performance-cache
>
> --
> Radim Vansa 
> JBoss Performance Team
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev