[infinispan-dev] Rollback and CacheEntry

[Vladimir Blagojevic]

Mircea,

I agree! I can store Delta changes under composite keys (delta key + 
actual map key) in tx context and when/if commit is issued these deltas 
can be merged into AHM. Great!

However, I would need to fiddle with ReadCommitedEntry#commit method. 
This method a bit of a kludge already and it would be great if we could 
introduce some indirection here in the form of some new CommitMethod 
interface. Impl of this interface could be passed to mvcc factory method 
when mvcc entries are created and invoked on CacheEntry#commit.

What do you think?

On 11-10-12 11:53 AM, Mircea Markus wrote:
> On 12 Oct 2011, at 10:46, Vladimir Blagojevic wrote:
>
>> Mircea,
>>
>> Maybe I should have sent the previous email only to you!
>>
>> The reason I want to do this is that FineGrainedMap cumulative delta changes are stored in AtomicHashMap itself.
> I think that causes a concurrency issue: if two tx operate on the same AHM then they will see each other's changes. The changes should be placed in the InvocationContext, or even better in the CacheTransaction object which represents the running transaction. See how CacheEntries are added to the context within the EntryWrappingInterceptor.
>> They are committed when commit is issued. However, I have not hook to clear these delta changes on rollback and they get accumulated for the next commit.
>>
>> Therefore this use case fails:
>>
>>    @Test(enabled=true)
>>    public void testRollbackAndThenCommit() throws Exception {
>>       final Cache<String, Object>  cache1 = cache(0, "atomic");
>>       final Cache<String, Object>  cache2 = cache(1, "atomic");
>>       final FineGrainedAtomicMap<String, String>  map1 = AtomicMapLookup.getFineGrainedAtomicMap(cache1, "testRollbackAndThenCommit",true);
>>
>>       tm(0, "atomic").begin();
>>       map1.put("k1", "v");
>>       map1.put("k2", "v2");
>>       tm(0, "atomic").rollback();
>>       FineGrainedAtomicMap<Object, Object>  map2 = AtomicMapLookup.getFineGrainedAtomicMap(cache2, "testRollbackAndThenCommit", true);
>>       assert !map2.containsKey("k1");
>>       assert !map1.containsKey("k1");
>>
>>       tm(0, "atomic").begin();
>>       map1.put("k3", "v3");
>>       map1.put("k4", "v4");
>>       tm(0, "atomic").commit();
>>
>>       assert map1.size() == 2&&  map2.size() == 2;
> I guess the failure is here as the map.size == 4?
>>    }
>>
>>
>> On 11-10-12 11:40 AM, Vladimir Blagojevic wrote:
>>> Hi Mircea,
>>>
>>> Can we make a hook to notify CacheEntry-ies in context that they have
>>> been rollbacked? We already have CacheEntry#rollback method but it is
>>> only called in ClusteringDependentLogic when commit fails.
>>>
>>> We could do this easily in EntryWrappingInterceptor. However, what would
>>> the effect be on the current codebase?
>>>
>>> Regards,
>>> Vladimir
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev