After Mircea's thorough review and advice from him and Sanne we are almost ready to integrate FineGrainedAtomicMap. I say almost because Sanne, Mircea and I concluded that two questions remain unanswered. 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.

2) This one is a bit technical. What should we do if tx1 deletes entire AtomicMap while tx2 updates entries in the same Map. Should we create a new Map and apply deltas to a new fresh map *or* simply discard delta changes because entire Map has been deleted?

On 17 Oct 2011, at 09:13, Dan Berindei wrote:

2) This one is a bit technical. What should we do if tx1 deletes entire AtomicMap while tx2 updates entries in the same Map. Should we create a new Map and apply deltas to a new fresh map *or* simply discard delta changes because entire Map has been deleted? I would say not simply discard the changes, but throw an exception and roll back tx2 as well. That would work. Also if a FGAM method is called and that FGAM has been deleted/replaced then the FGAM method should throw an exception.

>> 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?

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev