2 Replies Latest reply on Aug 31, 2011 1:17 PM by mircea.markus

    Design decision on cache modes / number of caches

    sudheerk84

      I have the follwing use case and would like  to know the ideal way to go about in such cases .

       

      Lets consider the example

       

      We have  6 nodes

      •     5 of the same kind(application containers) where user requests will be routed to them.
      •     The 6th node is a Risk engine which required data present in all these nodes.

       

       

      We use infinispan as a distributed , transactional cache , hidden behind our custom layer. We have written our custom layer similar to the spring cache abstraction layer.  Hence any updates to entities will be updated in the transactional manner in both database and infinispan cache.

       

      The 6th node which i have spoken above gets the data from all 5 nodes using cache listeners.

       

      Currently we have declared the cache to be replicated cache and hence , all account details are present in all 6 nodes.

       

      Is this teh right approach ?

       

      We  want all account details to be in the heap only for node 6. , and respective accounts to be in teh heap for nodes 1 to 5.

       

      Is there any suggestion on such usecases .

       

      Notes :

       

      For performance reasons node 6 should have all teh data cached .

      We would want a small heap in node 1 to 5 , and also the required data need to be cached locally rather than making remote calls.

      We just have a single cache definition, hence all objects are put into teh same cache. Do u think have a cache per node makes sence here ?

        • 1. Re: Design decision on cache modes / number of caches
          pmuir

          Infinispan doesn't support tieing of keys to nodes quite like you describe.

           

          The group API https://docs.jboss.org/author/display/ISPN/The+Grouping+API allows you to group certain keys, however it doesn't allow you to attach a group to a particular node (or group of nodes) as a first class construct (you could force it for one node by setting the group id to the address of a node I think). You could file a feature request for this.

           

          Your approach of creating 5 caches, one for each node 1 - 5, and all including node 6 won't work because Infinispan doesn't support asymetric clusters right now (where different nodes have different caches).

          1 of 1 people found this helpful
          • 2. Re: Design decision on cache modes / number of caches
            mircea.markus

            another possible architecture would be:

            - 5 nodes running a cluster in dist mode

            - the 6th BIG node to run independent and preload/configured to load data on demand, through a cluster cache loader, from the 5-nodes cluster

            1 of 1 people found this helpful