[infinispan-dev] TwoWayKey2StringMapper and keys which are never stored

[Mircea Markus]

On 12 Aug 2010, at 10:33, Sanne Grinovero wrote:

> Hello,
> While implementing a TwoWayKey2StringMapper for the Lucene Directory I
> noticed that
> it's mandatory to implement two-way conversions also for keys which
> I'm not going to ever store.
> 
> This directory has some different keys types, some need to be
> eventually storable (if a Store is configured),
> while some others are always handled with the Flag.SKIP_CACHE_STORE
> and should never be stored.
> 
> Still if I don't implement conversion of this type, I get a stacktrace
> about this type being not supported by
> the LuceneKey2StringMapper during rehashing.
> I'm not able to grasp the reason for this two-way key conversion to be
> needed for rehashing - I can only guess that you have good reasons for
> that - but I'm totally lost at why this implementation is being called
> for keys which I actually want to make sure they are never stored.
Let me try to explain how even the keys that are not persisted(SKIP_CACHE_STORE) get involved in rehashing.
Initial cluster {A,B}
C joins; C asks both A and B to supply the state that should be migrated to C (rehashing)
Both A and B do the following:
1.iterate over the in-memory state and collect the entries that should be moved to A
2. iterate over all the keys  in the cache store (but the in-memory ones), and again it collects all the entries that should be moved to A 
All the  entries collected in 1. and 2. are send back to A and which integrates them
A receives the entries  and writes them both in memory and in the cache store. Here is where you receive an exception: A doesn't know (and cannot know) which entries were not to be persisted(SKIP_CACHE_STORE), but it persists everything.  
> 
> Could this limitation be removed, or am I mandated to use two
> differently configured caches to store this information?
This would be a good solution: otherwise keys that you didn't want to be persisted (for a reason) would get persisted after rehashing. 
> 
> Regards,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev