note: MVCC should be enabled in connection url
In fact, this issue does not only replicate for refresh only, but every time we evict from the cache and reload an uncommitted entry:
So, it must be addresses such that once an entry is locked, the locked is not released when the entry is evicted.
h2 with MVCC
Do you think this issue fix should be added in 5.0 too?
I'll skip this one for 5.0.
I believe this is still broken for non-strict caching modes. The test that tries to provide coverage for this is falling victim to HHH-10707, and therefore non-strict isn't actually being tested. I'm guessing this should probably be reopened?
For NONSTRICT_READ_WRITE, there is no locking, and evict is not guaranteed to preserve data integrity guarantees. If you evict an entity, and you read it again, you can end up caching a non-committed entity version, so if you roll back that transaction you'll end up with a dirty read. I don't think this should be supported if there is no locking. What do you think?
The definition of nonstrict rw is pretty vague:
Read and write access (non-strict). Data may be added, removed and mutated. The non-strictness comes from the fact that locks are not maintained as tightly as in READ_WRITE, which leads to better throughput but may also lead to inconsistencies.
So this definition allows both dirty reads as well as stale reads. On the other hand, the implementation should offer as much consistency as possible without lowering throughput, so ideally only short window of stale reads (I consider dirty reads quite nasty). Your statement 'there is no locking' is more an implementation detail. Evict is said to 'Forcibly evict an item from the cache immediately without regard for transaction isolation', but it does not say it removes any locks or other metadata.