2. No. But you can create 2 separate caches using the same cache manager. This means they will share the same JGroups channel and networking layer, but the data organization on top of that could be different. Have a look at CacheManagerXmlConfigurationTest in Infinispan's core module for an example.
3. In both cases, it uses a non-blocking, chunked state transfer approach so that the existing cluster is not blocked (or is only blocked for a minimal amount of time). For more details, see http://jbosscache.blogspot.com/2009/03/jboss-cache-310beta1.html
Very cool, thanks for the reply. I had already been turned on to NBST by Bela Ben some time ago, good to know it's being used in Infinispan.
We'll look into creating different Caches - one replicated the other distirbuted - with one Manager, that sounds like th way to go for us.
Is there a lot of overhead in creating a bunch of different caches? I ask because we have a structure like this:
Inside CallPojo we have another ConcurrentHashMap:
So allCalls contains n Calls, each one with m Docs.
All Docs for a given Call have the same expiration time. But that expiration time is different for each Call. So it seems we need to use an Infinispan Cache inside of each CallDocPojo. Which means we'll have n Infinispan Caches.
Currently we have about 100 Calls and within each Call hundreds of Docs. Both of these numbers need to scale.
Is it wise to use 100+ Infinispan Caches?
Hmm, that could get expensive. Perhaps your best bet is to create a key that is a combination of call_id and document_id?
Yea, I thought it might be.
We're looking at concatenating the idCall onto the idDoc, and having one gigantic Cache, with Docs for all Calls, instead of n Cache, one for each Call.
This means we won't be able to define the expiration time at the Cache level; we'll have to do it each time we stick something in the Cache. But that's no big deal.
Thanks for your advice.