[hibernate-dev] 2LC docs
Vlad Mihalcea
mihalcea.vlad at gmail.com
Mon Jan 25 07:22:30 EST 2016
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 <rvansa at redhat.com> 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 <rvansa at redhat.com <mailto:
>> rvansa at 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 at redhat.com
>> <mailto:rvansa at redhat.com>
>> > <mailto:rvansa at redhat.com <mailto: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>
>> > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>
>> > > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>
>> <mailto: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.
>>
>> 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 at redhat.com <mailto:rvansa at redhat.com>>
>> JBoss Performance Team
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
>
More information about the hibernate-dev
mailing list