Partitioned cache/Buddy replication

[manik]

Somewhat early, but I thought I'd start a forum topic on this to start jotting down some thoughts around this.

Referenced JIRA tasks are JBCACHE-60 and JBCACHE-61

[manik]

Partial State Transfer ( http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3892213#3892213 ) will probably expose methods to invalidate subtrees in a cache, forcing state reload of the subtree from the cluster.

This may cause problems with buddy replication if invalidate() is called on data for which a node is the primary or backup source.

Some thoughts, for myself to follow up on:

- If the node is primary src, nominate a backup as a new primary before allowing an invalidate?
- If a node is a backup src, nominate a new backup src?
- If a backup src is being 'promoted' to a primary src, nominate a new backup src?

[manik]

Further thoughts on implementing this, snipped from email discussions:

- An 'address book' ('partition table'?) that is replicated across all nodes, containing FQNs and addresses of primary and backup nodes (Bela: and perhaps metadata?)

- local caches ('near cache' in Tangosol parlance) so when data is read from a remote node, it is maintained locally for a short while till cleaned up by an eviction policy. Bela: Yes, we can already do this with a remote cache loader

- Cache storage optimisation? Nominate nodes that use specific data objects the most to be owners of that data, reorganise the partition on the fly?