[infinispan-dev] FineGrainedAtomicMap - remaining items

[Manik Surtani]

Sorry for jumping in on this thread so late.  I've made comments on the pull request on GitHub, but anyway:

* We should not drop AtomicHashMap entirely. It serves a very different use case. Don't worry about confusing "users", this isn't a user API anyway.  It is meant as a building block targeted at power-users who understand how the internals work. Also it should be javadoc'ed clearly enough to minimise any confusion.

HTH
Manik


On 18 Oct 2011, at 13:28, Vladimir Blagojevic wrote:

> 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?
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org