[hibernate-dev] 2LC docs
Steve Ebersole
steve at hibernate.org
Mon Jan 25 13:02:45 EST 2016
+1. I think we need to generally understand a user guide and an
integration guide. Very different audiences.
On Mon, Jan 25, 2016 at 6:22 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:
> 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