[hibernate-dev] 2LC docs

[Radim Vansa]

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

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

That's why I am writing this mail, I want to clean it up and update.

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

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.

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

Thanks for consulting this with me!

Radim


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team