5 Replies Latest reply on Dec 8, 2002 6:05 PM by cpurdy

    ReplicationManager

    belaban

      Okay guys,

      let's get started !

      This forum is about caching on JBoss, and caching is either local or replicated. So a cache (basically a java.util.Map) contains keys and associated values which are cached locally (=in the same VM) or replicated to other caches, in different processes, possibly on different machines.

      Since I'm kind of biased (as the creator of JavaGroups) I thought we'd start out with the hard stuff first: the replicated cache. Maybe in parallel, we can also work on the local cache. The idea is to implement something similar to the JSR 177 (?) (JCache) spec (which is not yet out btw).

      The cache will be an MBean, providing a central service to many other parts of JBoss. This means the cache will be configured through MBean XML.

      Some use cases for the Cache I can think of will be:
      - Replacement of the EntityBean cache, which is currently not an MBean
      - Addition of replication functionality to the EntityBean cache. That way we can reduce access to the database for clustered entity beans some.
      - Replication service for other MBeans


      What do you think ?

      Bela

        • 1. Re: ReplicationManager
          cpurdy

          Hi Bela,

          Check with Sacha on the status, and you can reach me by email (cpurdy@tangosol.com).

          Peace,

          Cameron Purdy
          Tangosol, Inc.
          Coherence: Easily share live data across a cluster!

          • 2. Re: ReplicationManager
            marc.fleury

            > Okay guys,
            >
            > let's get started !
            >
            > This forum is about caching on JBoss, and caching is
            > either local or replicated. So a cache (basically a
            > java.util.Map) contains keys and associated values
            > which are cached locally (=in the same VM) or
            > replicated to other caches, in different processes,
            > possibly on different machines.

            I think we should early on integrate a separate kind of cache, the "persistent cache".

            A topology of machines can be N replicated caches (with various levels of locking and synchronization, I don't care about the real distributed locking that much) and then there is ONE cache that is persistent, meaning connected to a Relational database.

            So the network can look like

            VM--VM--VM--VM--VM
            |
            Persitent
            |
            DB

            SO that all caches are in VM for app server layer but one is configured persistent and in DB. BTW the EJB entities are the middle one, with the persistence turned on. I don't know that Dain has done serious work in separating the two cleanly but that is clearly something that we need to do once this is in place.

            The persistent cache uses CMP2.0 like sql behavior. Mapping the XML and table and such is something we should get from EJBCMP and JDO. I hear a ex-Castor lead wants to help on this effort and it would be a good place to have this guy work. His name is Bruce SNYDER. WE should also get the blevins guy from OpenEJB and have him work on this layer (the cache/persistent one).

            I do believe that JCache allows for pluggability of the loaders/storers. IN this instance we are talking about a loader/storer that goes to DB but that is also outfitted with a cache replication one. In other words, and I am not sure teh current JDO allows for this, we need 2 stores behind the persistent cache (one that works with DB, another one that works with cache replication).

            >
            > Since I'm kind of biased (as the creator of
            > JavaGroups) I thought we'd start out with the hard
            > stuff first: the replicated cache. Maybe in parallel,
            > we can also work on the local cache. The idea is to
            > implement something similar to the JSR 177 (?)
            > (JCache) spec (which is not yet out btw).
            >
            > The cache will be an MBean, providing a central
            > service to many other parts of JBoss. This means the
            > cache will be configured through MBean XML.
            >
            > Some use cases for the Cache I can think of will be:
            > - Replacement of the EntityBean cache, which is
            > currently not an MBean
            > - Addition of replication functionality to the
            > EntityBean cache. That way we can reduce access to
            > the database for clustered entity beans some.
            > - Replication service for other MBeans
            >
            >
            > What do you think ?
            >
            > Bela

            • 3. Re: ReplicationManager
              belaban

              Yes, persistency will be an attribute of a cache. Caches can be created as MBeans and there can be various sorts of caches, with different default behavior. For example:

              - Replicated synchronous cache with locking. However, individual methods can override this default, e.g.

              boolean use_locks=false;
              boolean async_mode=true;
              cache.put(name, value, use_locks, asyn_mode);

              will send an update asynchronously, deviating from the default.

              - Local cache with persistent backup

              - Replicated asynchronous cache with persisten backup etc etc etc

              Same goes for persistency. I opt for XML to configure caches.

              As for the one cache that's backed up by persistent store: we can define this statically, or we can even make this dynamic, e.g. the oldest cache always stores into a database. When this guys is killed someone else takes over etc. we can get into pretty elaborate schemes here.

              We might use interceptors for the cache backend(s), e.g. we could have a replicated cache, which is backed by a database and logs statistics to a file, which would look like this:

              Cache
              |
              |
              ReplicationInterceptor
              |
              |
              PersistentInterceptor
              |
              |
              StatisticsInterceptor


              I added this feature to the TODO list

              Bela

              • 4. Re: ReplicationManager
                cpurdy

                JCache is JSR 107 ... I thought we already had someone from JBoss represented there, but if not, then we should probably suggest it to the JSR group. If you want me to bring it up at the next JSR meeting, just drop me an email.

                Peace,

                Cameron Purdy
                Tangosol, Inc.
                Coherence: Easily share live data across a cluster!

                • 5. Re: ReplicationManager
                  belaban

                  Hi Cameron,

                  I think Sacha applied some time ago, or at least wanted to. I'm not sure if he ever actually did it.

                  Bela