[hibernate-dev] 2LC docs

[Steve Ebersole]

On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa at 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 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?
>

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.