1 Reply Latest reply on Jan 22, 2007 9:40 AM by Manik Surtani

    JBCACHE-941 discussion

    Elias Ross Master

      http://jira.jboss.com/jira/browse/JBCACHE-941

      From the issue:

      The java.util.Collections utility class supplies useful methods for dealing with legacy interfaces and wrapping collection classes for concurrency, type safety, read-only, etc.

      In a simiilar vein, I wrote a "Caches" class that returns java.util.Map instances for a Node, which allow data to be modified through the standard Map interface.

      This I expect to be extremely useful for allowing uses to integrate their existing application with JBoss Cache, and will eliminate some of the confusion of using a new API and they can use the API they know best. Users also often demand an API which is "generic" so that their code is not tied to a particular vendor.

      There are basically two methods in Caches, one looks like this:

      Cache cache = DefaultCacheFactory.getInstance().createCache();
      Map m = Caches.asMap(cache);
      m.put("foo", "bar");

      The API and examples explain themselves.

      "Caches" could also include other useful methods for printing or reporting.

      Note that this functionality could be considered duplicated from PojoCache...


      Here is one method:
      /**
       * Returns a {@link Map}, where map keys are named children of the given Node,
       * and values are kept under a single key for this node.
       * The map may be safely concurrently modified through this Map or externally,
       * and its contents reflect the cache state and
       * existing data of the Node.
       * This means that {@link ConcurrentModificationException} is never thrown
       * and all methods are thread safe.
       * <p/>
       * The map is not serializable.
       * <p/>
       * Usage note: As a single node is used for every key, it is most efficient to store
       * data for a single entity (e.g. Person) in a single object.
       * <p/>
       * Also, when using a {@link CacheLoader} for storage, keys used must be valid as
       * part of the {@link Fqn} used in calls. Generally speaking, simple string values are
       * preferred.
       */


      Manik suggests also an adaptor for JCache (JSR-107).

      Actually, it might also be nifty if JBoss Cache could supply adaptors for competing Cache APIs. I'm not sure of the legality of this for commercially published interfaces.

        • 1. Re: JBCACHE-941 discussion
          Manik Surtani Master

           



          Manik suggests also an adaptor for JCache (JSR-107).



          Just that JCACHE uses a Map interface rather than a tree structured one.

          In general, I think this is a good idea as there are many use cases (Hibernate, among others) where a tree structure is too complex and unnecessary from an API perspective (but necessary from a performance/efficiency perspective).

          E.g., Coherence offers a Map interface, but internally key/value pairs are broken up into buckets for finer grained concurrency and replication.


          Actually, it might also be nifty if JBoss Cache could supply adaptors for competing Cache APIs. I'm not sure of the legality of this for commercially published interfaces.


          Hmm, this would mean shipping with those interfaces though. Perhaps these could be additional downloads? Like you said, we'd need to research legality anyway.