4 Replies Latest reply on Jun 23, 2016 5:06 PM by mjhaller

    Eviction and Infinispan as a second level cache provider

    mjhaller

      Infinispan: Hibernate Second Level Cache improvements states:

       

      There is one downside of the current implementation - you should not use eviction, as eviction cannot tell regular entity (which can be evicted) from the tombstone. If tombstone was evicted, there's a risk of inconsistent reads. So when using replicated caches, you should rely on expiration to keep your cache slender. We hope that eventually we'll remove this limitation.

       

      But, the cache expires at 10,000 entries by default.   We have a replicated cluster using Hibernate 5.0.6.Final  (the latest supported by Hibernate Search), and Infinispan 8.1.   So, I assume we have to use EvictionStrategy.NONE, until the eviction limitations are removed?   Is there a plan on when these limitations will be removed?

        • 1. Re: Eviction and Infinispan as a second level cache provider
          rvansa

          The limitation applies only to the caches in replication mode, which use tombstones. Default configuration has invalidation-mode caches with 10k entries, and this combination is safe.

           

          I apologize if the blogpost is not clear in this matter (I'll reformulate it). The table on the bottom shows that eviction is allowed in invalidation mode.

          • 2. Re: Eviction and Infinispan as a second level cache provider
            mjhaller

            I think the blog post is clear, especially that nice little table at the end.  However, we are using replication, as seen below:

             

             

            <?xml version="1.0" encoding="UTF-8"?>
            <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="urn:infinispan:config:8.1 http://www.infinispan.org/schemas/infinispan-config-8.1.xsd
                                        urn:infinispan:config:store:jdbc:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-jpa-config-8.0.xsd"
                xmlns="urn:infinispan:config:8.1">
                <jgroups>
                    <stack-file name="external-file" path="jgroups-l2cache.xml" />    
                </jgroups>
                <cache-container default-cache="default" statistics="true">
                    <transport stack="external-file" />
                    <distributed-cache-configuration name="entity" statistics="true" />
                    <distributed-cache-configuration name="distributed-query" statistics="true" />
                </cache-container>
            </infinispan>
            

             

            With this configuration it seems we must use EvictionStrategy.NONE, correct?

             

             ...
              <prop key="hibernate.cache.infinispan.eviction.strategy">NONE</prop>
            ...
            


            • 3. Re: Eviction and Infinispan as a second level cache provider
              rvansa

              The config you show uses distribution, and that means that the record in cache will have 2 copies (or 1 if there's single node). Replication will keep a copy on each node, therefore the reads will be local (as long as the entity is in the cache), with distributed cache, some reads cause RPC, and going to different node can be as slow as going to DB machine.

               

              But yes, with both distributed and replicated caches, you have to disable eviction, either through hibernate properties as you suggest, or through configuration:

               

              <distributed-cache-configuration name="entity">

                 <eviction strategy="NONE"/>

              </distributed-cache-configuration>

               

              Actually no eviction is the default, so unless you override it through hibernate properties, you configuration should not use eviction.

              If you want to avoid having too many unused entities in the cache, you can set expiration and entries that are not read for a while will get purged out of the cache:

               

              <distributed-cache-configuration name="entity">

                 <eviction strategy="NONE"/>

                 <expiration max-idle="3600000"/>

              </distributed-cache-configuration>

               

              Though, when you want to limit absolute number of entities, you have to tune the value according to you app's behaviour.

              • 4. Re: Eviction and Infinispan as a second level cache provider
                mjhaller

                Thank you very much Radim.   Just wanted to post the conclusion and say thanks:

                 

                We decided to go with the recommended invalidation mode.  Here is our current config, which is working well:

                 

                <?xml version="1.0" encoding="UTF-8"?>
                <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    xsi:schemaLocation="urn:infinispan:config:8.1 http://www.infinispan.org/schemas/infinispan-config-8.1.xsd
                                            urn:infinispan:config:store:jdbc:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-jpa-config-8.0.xsd"
                    xmlns="urn:infinispan:config:8.1">
                    <jgroups>
                        <stack-file name="external-file" path="jgroups-l2cache.xml" />    
                    </jgroups>
                    <cache-container default-cache="default" statistics="true">
                        <transport stack="external-file" />
                       
                  <invalidation-cache-configuration name="entity">
                    <eviction strategy="LRU" max-entries="40000" />
                  </invalidation-cache-configuration>        
                    </cache-container>
                </infinispan>
                

                 

                 

                We also enabled a query cache, but are still benchmarking that.