Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
We are using ehcache replication for two different applications.
The application A has cache 1 and cache 2 in ehcache.xml.
The application B has cache 1 in ehcache.xml. The application B does not have cache 2 in ehcache.xml.
For replication between two application, we are using same multicastGroupAddress and multicastGroupPort.
What will happen if we put data in cache 2 of Application A. Will it try to replicate data in Application B? How will it work?
If you only use java primitives, then it doesn't matter much.. Just make sure that if they both use the same cache-name, they're caching the same thing. You can selectively target specific caches to be replicated or not. I'm not sure if you can have the same cache-manager use multiple replication configurations (e.g. different multicast ports), but if you did, you could have application-specific caches only replicate between like applications.
For non-primitives, you just need to make sure there is a common jar file that defines the same class structure and hierarchy.. This includes ANYTHING that might be referenced by those classes. The entire object-graph is serialized on each replication event. The only difference is whether you need to serialize just the key, or the key and value pair. I tend to only care about cache coherency, and thus I only replicate 'dirty events', not put events. Thus I only ever serialize keys. But your use case may be different.
Note, the real issue is during upgrades. Because one application will have a newer jar file than the other. You either need to take everything down at once, or make sure that you're only adding/removing columns, not renaming/re-typing columns in the replication process. java serialization will ignore fields that don't exist locally, but if there's a type-mismatch (especially if there's a new type), then an exception will be thrown on serialization. At high rates, this can have major performance impact - to say nothing of the lack of cache coherency.
Again, this points back to trying to only replicate basic java types (primitives, maps, dates, etc).
Sorry, to respect more directly to your questions. Yes, you can have mismatches of caches between the applications.
cache1, cache2 in A
cache1 in B
is perfectly fine.
As long as you're not hot changing caches at runtime.. There is generally a startup 'discovery process' in the various ehcache replication environments (RMI, jgroups.. not sure about terracotta), where each node knows which remote caches it wants to inform local changes about.
I am not sure whether app A will try to inform app B about changes to cache2 (with respect to RMI.. with jgroups everybody gets notified anyway), but app B would ignore any such events (because no cache named cache2 exists).