Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Replication between two different Application

Developers
2010-07-29
2013-05-14
  • Maulin Rathod
    Maulin Rathod
    2010-07-29

    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).