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