[infinispan-dev] Read Committed Distributed Cache Concerns

[Sanne Grinovero]

On 19 September 2013 09:06, Radim Vansa <rvansa at redhat.com> wrote:
> I think that Read Committed isolation level is not obliged to present
> you with up-to-date committed data - the only fact is that it can, but
> application must not rely on that. It's lower isolation level.
> Nevertheless, I think that lower isolation level should mean better
> performance. I would be strongly against imposing any additional
> overhead that could slow it down. I should give it some test, but if it
> currently does not offer any advantage against RR, I don't see any
> reason for this to exist.

+1
I also think the lower level of isolation is not necessarily a
promise, more something people can select when they are able to handle
it in their apps / business requirements.
As long as this is properly documented it should be fine.

I agree with your point that it's undesirable that depending on the
node topology (i.e. on which node you happen to run a test) the
experienced isolation might seem different, but again let's just
document it clearly.

>
> Regarding the bug: Thanks a lot for pointing this out, I should adapt
> the testsuite to use different object types as values (if I understand
> the scenario correctly).
>
> Radim
>
> On 09/19/2013 12:03 AM, William Burns wrote:
>> I was recently refactoring code dealing with isolation levels and
>> found how ReadCommitted is implemented and I have a few concerns I
>> wanted to bring up.
>>
>> ReadCommitted read operations work by storing a reference to the value
>> from the data store in its caller's context.  Thus whenever another
>> transaction is committed that updates the data store value any context
>> that has that reference now sees the latest committed value.  This
>> works well for Local and Replicated caches since all data stores are
>> updated with the latest value upon completion of the transaction.
>> However Distributed caches only the owners see the update in their
>> data store and thus any non owner will still have the old value they
>> previously read before the commit occurred.
>>
>> This seems quite inconsistent that Distributed caches run in a mix of
>> Repeatable Read/Read Committed depending on what node and what key you
>> are using.
>>
>> To operate properly we could track requests similar to how it works
>> for L1 so we can tell non owners to clear out their context values for
>> values they read remotely that they haven't updated (since Read
>> Committed writes should return the same written value).  That seems
>> like quite a bit of additional overhead though.
>>
>> I am wondering is it worth it to try to keep Read Committed isolation
>> level though?  It seems that Repeatable Read would be simpler and most
>> likely more performant as you wouldn't need all the additional remote
>> calls to get it to work properly.  Or is it okay that we have
>> different isolation levels for some keys on some nodes?  This could be
>> quite confusing if a user was using a local and remote transaction and
>> a transaction may not see the other's committed changes when they
>> expect to.
>>
>> What do you guys think?
>>
>>   - Will
>>
>> P.S.
>>
>> I also found a bug with Read Committed for all caches where if you do
>> a write that changes the underlying InternalCacheEntry to a new type,
>> that reads won't see subsequent committed values.  This is caused
>> because the underlying data is changed to a new reference and a read
>> would still be holding onto a reference of the old InternalCacheEntry.
>>   This can happen when using the various overridden put methods for
>> example.  We should have a good solution for it, but may not be
>> required if we find that Read Committed itself is flawed beyond
>> saving.
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev