[infinispan-dev] [ISPN-6] Switch to distribution for default entity/collection cache?

Galder Zamarreno galder.zamarreno at redhat.com
Wed Sep 2 05:47:47 EDT 2009


Hi,

While working on documenting the Infinispan cache provider, I've been 
thinking on the default cache settings for each Hibernate type:

- Entity/Collection: Bearing in mind the requirement to keep this cache 
synchronous, in the past we've gone for invalidation rather than 
replication because using replication could mean having to replicate a 
lot of data to all nodes in the cluster. For Infinispan however, I was 
thinking of the possibility of making sync distribution default for 
entities though since we are not replicating to everyone any more.

One doubt I have about here is how much of an advantage would be to 
bring an entity from another node in the cluster if present 
(distribution) vs loading it from the database if not available in the 
local cache (invalidation).

The one downside I see of distribution vs invalidation is that if an 
entity is not available locally and is not available in the cluster, 
distribution is more expensive that invalidation, since dist involves 
round trip in cluster and round trip to database, vs round trip to 
database with invalidation.

However, unless eviction kicks in, this should only affect the 1st time 
an entity/collection is queried cos the next time, it will be 
distributed already and potentially in the L1 of the node that requested 
it if it's not one of the owners.

So, I think I would make distribution default for entity/collection. 
Thoughts? I'd still leave an invalidated configuration in the default 
config file so that people can potentially swap to it if they want to.

- Query: I think we should stick to same JBC2/3 default here which is 
local.

- Timestamps: Given the chattiness of this cache, and the low size 
payloads, asynchronous replication still looks to me like a good default 
for this cache.

Cheers,
-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache



More information about the infinispan-dev mailing list