Re: [hibernate-dev] Consistency guarantees of second level cache

Yes, and maybe in general you allow users to pick between such a strict/nonstrict mode. On Thu, Sep 10, 2015 at 2:47 AM Radim Vansa wrote: > On 09/09/2015 06:16 PM, Steve Ebersole wrote: > > Some comments inline and then a general discussion at the end... > > > > On Wed, Sep 9, 2015 at 10:32 AM

Re: [hibernate-dev] Consistency guarantees of second level cache

On 09/09/2015 06:16 PM, Steve Ebersole wrote: > Some comments inline and then a general discussion at the end... > > On Wed, Sep 9, 2015 at 10:32 AM Radim Vansa > wrote: > > Thanks for correcting the terms, I'll try to use 'isolation'. > > TX2 reading B = 1 is not

Re: [hibernate-dev] Consistency guarantees of second level cache

Some comments inline and then a general discussion at the end... On Wed, Sep 9, 2015 at 10:32 AM Radim Vansa wrote: > Thanks for correcting the terms, I'll try to use 'isolation'. > > TX2 reading B = 1 is not READ_UNCOMMITTED - value B = 1 was committed > long ago (it's the initial value). It's

Re: [hibernate-dev] Consistency guarantees of second level cache

Thanks for correcting the terms, I'll try to use 'isolation'. TX2 reading B = 1 is not READ_UNCOMMITTED - value B = 1 was committed long ago (it's the initial value). It's reading A = 2 what can be considered read uncommitted (not isolated enough), but as the cache has nothing to do with that e

Re: [hibernate-dev] Consistency guarantees of second level cache

To be precise when you talk the stale data you are really asking about isolation. TX2 reading "B->1" before TX1 commits is a question of isolation and preventing READ_UNCOMMITTED access to the data. The problem is the split in the notion of "commit". Those should be "as close together as possibl