[infinispan-dev] FineGrainedAtomicMap - remaining items

Vladimir Blagojevic vblagoje at redhat.com
Tue Oct 18 08:28:48 EDT 2011


On 11-10-17 11:19 AM, Mircea Markus wrote:
>
>>> 1) Should we stick fine-grained functionality under current AtomicMap
>>> and discard legacy AtomicMap? FineGrainedAtomicMap seems to offer a
>>> super-set of AtomicMap features and we should not confuse users with yet
>>> another AtomicMap; at the same time we have less headache maintaining
>>> AtomicMap codebase.
>>>
>>
>> How's the performance of the fine grained AtomicMap compared to the 
>> old one?
>> If the performance is identical then I see no reason to keep the old
>> one around, otherwise we already have problems keeping up with the
>> performance of JBossCache 1.4 (see
>> http://community.jboss.org/message/630238) so I would keep the old one
>> around.
>
> +1. A simple test that does puts would tell us that straight away.
> If we choose to allow both fine grained(FGAM) and non-faine grained 
> maps(AM), then we also need to be concerned with the following 
> transactional aspect: what happens if tx1 access key "k" using a FGAM 
> and tx access same "k" using an AM. Perhaps not allow that kind of 
> mixed access for now?
>
I doubt that performance of of FGAM can be much worse than AM. If we 
have multiple tx initiated across several nodes on a certain AM, AM 
performance can degrade due to the fact that we have to serialize these 
txs since they all access the same key k;  FGAM performance I would 
presume can only be better due to lock splitting nature of FGAM (I 
assume ordered key locking in FGAM). Everything else is pretty much the 
same (network payload, read semantics, round trips necessary etc)

Mircea, we already prevent having FGAM created under key k if was AM 
previously created under the same key k. However, this is node local 
now, we would also have to prevent users from mixing FGAM and AM created 
under the same key from different nodes. Ughhh!

On top of all these we would majorly confuse our users with FGAM and AM 
subtleties! We would complicate API on top of it! Major confusion!

Lets play devils advocate! Can anyone envision a scenario where FGAM 
cannot replace AM? I can one. It is related to deletion of a map. If we 
have two txs, say t1 deletes map and t2 updates a map. In AM we would 
either end up with no map under key k or we would have updates from t2 
in map only - depending on which tx gets executed first. If we want to 
replace AM then we would have to do something similar.

Anything else?









More information about the infinispan-dev mailing list