[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

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

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

[hibernate-dev] Released Hibernate Search 5.5.0.CR1

We just released Hibernate Search 5.5.0.CR1 ! It includes several improvements and lots of fixes, please see the blog post: http://in.relation.to/2015/09/09/Hibernate-Search-5/ Thanks for all feedback already! Regards, Sanne ___ hibernate-dev

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

Re: [hibernate-dev] HQL and spatial

Hi Steve, > On 08 Sep 2015, at 22:29, Steve Ebersole wrote: > > What do you mean "have these functions integrated into HQL"? What you > describe is exactly how sql functions are supported as well. Perhaps you > mean defining standard support for spatial functions.