4 Replies Latest reply on Aug 31, 2015 4:15 AM by rvansa

    Is Infinispan always deterministic about Entities and Collections ?


      Hi all!

      We are planning to use a cache for our Entities. There is something I don't understand well from the documentation. About Caching entities I can read:

      "For all entities and collections, whenever a new entity or collection is read from database and needs to be cached, it’s only cached locally in order to reduce intra-cluster traffic. This option cannot be changed."



      "All entities and collections are configured to use a synchronous invalidation as clustering mode. This means that when an entity is updated, the updated cache will send a message to the other members of the cluster telling them that the entity has been modified. Upon receipt of this message, the other nodes will remove this data from their local cache, if it was stored there. "


      So my question is: Why an invalidation message is required if data is cached only locally ? In other words, which are the scenarios when an Entity is stored on multiple nodes ?

      I can figure out only two options:

      1) The node with the Entity was shutdown. But then still when the Entity is loaded again it will still remain on the local node only.

      2) Infinispan is not 100% deterministic, so it means that sometimes attempts to load the Entity from a node where the Entity was not loaded. (BTW how can we improve it ?)


      We would need to understand the last point so that we can discriminate to use the hibernate cache or not.



        • 1. Re: Is Infinispan always deterministic about Entities and Collections ?

          The invalidation cache is tailored to be used for Hibernate second-level caching, where you have DB (authoritative source) and Infinispan cache (with expiration, eviction, some data are not loaded from the DB yet etc.) Infinispan cache should always provide same data as those stored in DB, or don't provide the entity at all.


          So you have several caching nodes, all connected to single DB. Each node can load the data from DB and cache it locally - the same entity, with the same key. However, when (possibly third) node updates/deletes the entry from DB, the caches on other nodes should not provide the cached value anymore, therefore, they need to get to know that the locally-cached entity should be removed. And that's what the invalidation cache does.


          If you're to use second-level caching in your app, I'd strongly recommend trying Hibernate 5 (5.0.0.Final was publicly released week ago). There are few flaws in Hibernate 4.x implementation that can make the cache provide results inconsistent with DB (stale data). I think that some fixed did not make it to 5.0.0.Final (will get to 5.0.1) but upgrading micro version is easy as soon as that's out.

          • 2. Re: Is Infinispan always deterministic about Entities and Collections ?

            Hi Radim,

            thanks for your reply. Just one clarification, the "hibernate" invalidation cache is independent from the second-level cache ? I mean you need to activate the 2LC on the applicaiton server in order to have the invalidation + local query + timestamp caches working ?



            • 3. Re: Is Infinispan always deterministic about Entities and Collections ?

              The application server already has an active 2nd Level cache. You only need to activate it inside of the persistence.xml in your application.

              If you use hibernate direct ou need to configure it there in this case the server-cacheis not used.

              • 4. Re: Is Infinispan always deterministic about Entities and Collections ?

                I don't fully understand the question, but there are two things: Infinispan invalidation-mode cache (which is just one way how the cache may operate), and then there's the pluggable second-level cache support in Hibernate ORM. One implementation of this (hibernate-infinispan module) integrates Infinispan, and (as an implementation detail) uses invalidation-mode cache for entities.