[infinispan-dev] FineGrainedAtomicMap preview

[Vladimir Blagojevic]

Hi Mircea,

I reimplemented fine grained maps not to rely on synchronization hook 
callback. I treat applyDelta just as any other write command. This way 
we can piggyback on our tx infrastructure. I am putting finishing 
touches on it now and will ask for a review soon.

Barring some unforeseen problems I hope to finish it completely this week.

Regards,
Vladimir

On 11-10-07 5:13 PM, Vladimir Blagojevic wrote:
> On 11-10-07 12:27 AM, Vladimir Blagojevic wrote:
>>> In order to understand the issue I needed to look into the entire
>>> code. Here are some observations:
>>> - you shouldn't register a sync for applying the atomic map changes.
>>> Why? There are several reasons for that, the main one being that with
>>> this approach FGAM would't be able to participate in distributed
>>> transactions.
>>> I don't see where the FGAM's entries that are added within a
>>> transaction's scope are merged within the existing entries in the
>>> FGAM. What do code does is keep all transaction-scoped entries in the
>>> data container's FGAM instance, even if they are not committed.
>>> This test fails and it obviously shouldn't:
>>> https://gist.github.com/1267303
>> Yes it fails. To be honest I did not think we need to support this. So
>> for every delta change on AtomicMap I need to keep undo operation
>> around? Manik and I completely overlooked this in our brainstorming.
> I get it now, of course we need to support this. How AtomicMap
> implemented rollbacks is by invoking cache put with delta key and a
> value of AtomicMap write clone for each write operation on AtomicMap in
> tx scope. If tx rollback got issued you just go back to version before
> writes to AtomicMap and your UT passes as it does for legacy AtomicMap.
>
> However, I can not do this now in fine grained atomic map as we can not
> lock on delta key anymore (we were locking on delta keys because we
> invoked put with delta key an AtomicMap value). I need to talk to Manik
> about this :-)
>
> Vladimir
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev