3 Replies Latest reply on Apr 1, 2009 10:13 AM by brian.stansberry

    True Structure of Cache Node?

    atifoxon

      I need some explanation of the structure of the Node interface. Below are some excerpt from documentation

      From Interface Node<K,V> Documentation
      A Node is a named logical grouping of data in the JBoss Cache. A node should be used to contain data for a single data record, for example information about a particular person or account.

      From Interface Interface Cache<K,V> Documentation

      // creates with default settings and starts the cache
      
      Cache cache = DefaultCacheFactory.getInstance().createCache();
      Fqn personRecords = Fqn.fromString("/org/mycompany/personRecords");
      
      
      Node rootNode = cache.getRoot();
      Node personRecordsNode = rootNode.addChild(personRecords);
      
      // now add some person records. Fqn peterGriffin = Fqn.fromString("/peterGriffin");
      
      // the addChild() API uses relative Fqns
      Node peter = personRecordsNode.addChild(peterGriffin);
      
      peter.put("name", "Peter Griffin");
      peter.put("ageGroup", "MidLifeCrisis"); peter.put("homicidal", Boolean.FALSE);
      


      Correct me if I have misunderstood it

      [1] According to above two a node should contain data related to one record of database
      [2] If 1 is correct then each node should store data in from of colName, colValue pair

      Is above scheme recommended one or I can use it other way around ? e.g.

      [A] I am storing a record in individual nodes as a object against PK of that record and not in colName, colValue fashion. so my cache contains one node per record and each node's map contains only one value which is the record VO (value object). I think I am wasting the maps associated with nodes by doing this. What is your opinion?

      [B] If I store set of records at node rather than one record (not correct according to API docs), so my cache contains one node per table. I think this way I am utilizing the node's map. What is your opinion?

        • 1. Re: True Structure of Cache Node?
          genman


          Although it may seem strange to store a single value in a Node, fortunately, JBoss Cache is designed to be somewhat efficient at storing a single name-value pair in a Node instance. So try and stick with [1].

          • 2. Re: True Structure of Cache Node?
            atifoxon

            Can anyone comment on [A] and other strategies. Is [A] a recommended approach and is not wastage of node maps?

            Anyone from JBoss Cache developer can comment on it? As it is primary concern when building cache

            • 3. Re: True Structure of Cache Node?
              brian.stansberry

              genman is a significant JBoss Cache developer and he commented on it, correctly. :)

              Single-key per node is very common. Hibernate Second Level Cache with JBC works that way. JBoss AS EJB3 StatefulSessionBean caching works that way. Some flavors of JBoss AS HttpSession caching work that way.

              Whether you put a single key with a coarse grained value object or multiple keys with finer grained value objects depends on how you use the data, particularly how you update it after the initial placement in the cache. Multiple keys allow you to update a single key and just replicate that new value, avoiding re-replicating the other unchanged key/value pairs.

              Note that updating/replicating just a single key/value is not advised if other values in the map share references to objects included in the replicated value's object graph. (Example: key "husband" and value Person object, key "wife" and value Person object, both Person objects share a ref to an Address object). This is because when an object is independently replicated, it is independently serialized/deserialized, and on the other cluster nodes shared references are broken (husband and wife no longer have a ref to the same Address object, rather 2 Address objects with -- initially -- the same data.)

              If you are using INVALIDATION, multiple keys has no benefit as the invalidation message invalidates the entire node.