Hi Radim,
I'll have to port the CorrectnessTesCase to EhCache too.
The Refresh test case uses H2 explicitly because I wanted to make sure that
we always run this test on an MVCC DB (the test sets the MVCC flag in the
connection URL).
If the underlying DB uses 2PL, the test will halt. The test can
Hi Vlad,
I think that this change is safe (it uses only the supported flow of 2LC
SPI calls), though it introduces a bit more overhead for the refresh.
FYI, besides unit tests, there's CorrectnessTestCase [1] - I've used
this one to find out most of flaws in Infinispan 2LC impl. Could be
worth
On 04/06/2016 11:58 AM, Radim Vansa wrote:
> On 04/05/2016 04:13 PM, Vlad Mihalcea wrote:
>> Hi,
>>
>> I'd definitely fix it for the refresh operation, which does an implicit
>> cache eviction too.
>> In this case, the proposed PR solution is fine since it simply locks the
>> entry right after it i
Hi Radim,
I pushed this fix on master and 5.1, and I managed to add an EHCache where
the same behavior was replicated as well:
https://github.com/hibernate/hibernate-orm/commit/cbdab9d87f05b4255c7930a32fe995f87f0f3e0b
For Infinispan, I think it's better if you can investigate if this is an
issue
On 04/05/2016 04:13 PM, Vlad Mihalcea wrote:
> Hi,
>
> I'd definitely fix it for the refresh operation, which does an implicit
> cache eviction too.
> In this case, the proposed PR solution is fine since it simply locks the
> entry right after it is evicted from the cache and releases the lock afte
That's exactly what I mean too. I think we can improve it a little bit when
the evict is forced while being on running Session.
But that's not in the scope of the original issue which stays as is.
I'll add a new Jira issue with a test case, and a design change proposal
that we can discuss when we
The contract for SessionFactory-level even says that it operates outside of
the confines of an Session-based locking of the cached data. So it works
this way by design. We can question the design decision, but that's a
different discussion.
On Tue, Apr 5, 2016 at 9:38 AM Vlad Mihalcea
wrote:
>
Hi,
I'd definitely fix it for the refresh operation, which does an implicit
cache eviction too.
In this case, the proposed PR solution is fine since it simply locks the
entry right after it is evicted from the cache and releases the lock after
the transaction is ended.
This way, we won't push an u
On 5 April 2016 at 14:11, Vlad Mihalcea wrote:
> Hi,
>
> While reviewing the PR for this issue:
>
> https://hibernate.atlassian.net/browse/HHH-10649
>
> I realized that the ReadWrite cache concurrency strategy has a flaw that
> permits "read uncommitted" anomalies.
> The RW cache concurrency strat
