[hibernate-dev] 2LC docs

[Steve Ebersole]

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

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