2 Replies Latest reply on Sep 14, 2011 11:33 AM by darrellburgan

    Number of named caches - practical limit?

    darrellburgan
    darrellburgan Sep 12, 2011 7:10 PM

      We are in process of updating our in-house custom ORM to use Infinispan as a caching mechanism. Without debating the virtue of having an in-house ORM (we wish we didn't but moving to JPA is a longer-term project), a question that arises is how we map objects in our current ORM to caches in Infinispan.

       

      The approach I would like to take is for each table to have multiple caches, one for the primary key cache and others for each secondary key, each with a distinct cache name. The result is that for a given table there would always be at least one named cache and potentially several. A typical table might have 2-3 caches.

       

      Given there could be as many as 100 cached tables, the number of named caches proliferates quickly. My question is whether this is a bad idea given Infinispan's design? Will Infinispan be okay with so many named caches all being managed from a single cache manager? Is this atypical usage of Infinispan or should I not be worried about this?

       

      Thanks in advance for any help!

       

      Darrell Burgan

        • 1. Re: Number of named caches - practical limit?
          manik
          manik Sep 14, 2011 7:55 AM (in response to darrellburgan)

          Several hundred caches should not be a problem, as this happens when using Infinispan as a 2nd level cache for Hibernate.  But be aware that there is an issue at the moment which affects startup time when you have hundreds of caches. See this forum thread for related info, this will be addressed as a part of ISPN-1321. Don't be put off by it though, the reporter was creating thousands of caches and even then, the slowdown is only at boot time, not runtime.

            • Actions
          • 2. Re: Number of named caches - practical limit?
            darrellburgan
            darrellburgan Sep 14, 2011 11:33 AM (in response to manik)

            Okay thanks, good to know that Hibernate is approaching the table-to-cache mapping problem in a somewhat similar way and Infinispan is made to support that. We will be ramping up our conversion to Infinispan relatively slowly, converting tables one at a time from our old/terrible in-house caching scheme to Infinispan, so it will likely be at least some months before the startup delay really becomes a noticeable problem.

             

            Is there a rough timeline for 5.1.0?

             

            Thanks so much for your help.

             

            Cheers,

            Darrell Burgan

              • Actions