-
1. Re: A few (hopefully) quick questions
manik Oct 26, 2009 6:00 AM (in response to syg6)Hi.
1. No.
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
Cheers
Manik -
2. Re: A few (hopefully) quick questions
syg6 Oct 27, 2009 5:03 AM (in response to syg6)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.
Thanks again.
Bob -
3. Re: A few (hopefully) quick questions
syg6 Oct 27, 2009 12:02 PM (in response to syg6)Is there a lot of overhead in creating a bunch of different caches? I ask because we have a structure like this:
ConcurrentHashMap<String,CallPojo> allCalls
Inside CallPojo we have another ConcurrentHashMap:
ConcurrentHashMap<String,CallDocPojo> allCallDocs
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?
Bob -
4. Re: A few (hopefully) quick questions
manik Oct 27, 2009 12:17 PM (in response to syg6)Hmm, that could get expensive. Perhaps your best bet is to create a key that is a combination of call_id and document_id?
-
5. Re: A few (hopefully) quick questions
syg6 Oct 28, 2009 6:34 AM (in response to syg6)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.
Bob