2 Replies Latest reply on Aug 30, 2005 8:41 AM by Manik Surtani

    Partitioned cache/Buddy replication

    Manik Surtani Master

      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



        • 1. Re: Partitioned cache/Buddy replication
          Manik Surtani Master

          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?

          • 2. Re: Partitioned cache/Buddy replication
            Manik Surtani Master

            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?