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

[hibernate-dev] Consistency guarantees of second level cache

Hi, I've been fixing a lot of consistency issues in Infinispan 2LC lately and also trying to improve performance. When reasoning about consistency guarantees I've usually assumed that we don't want to provide stale entries from the cache after the DB commits - that means, we have to invalidate