6 Replies Latest reply on Aug 8, 2017 10:31 AM by Vladimir Dzhuvinov

    Peculiar behavior of invalidation-cache?

    Wayne Wang Apprentice



      I was investigating the invalidation-cache setting for entity in wildfly 10.1.0, and found some peculiar behavior. I am not sure if this is by design or if I need to make any configuration change.


      I used the out-of-box standalone-full-ha.xml to start up the two wildfly instances


      I have a cluster of two wildfly 10.1.0.Final instance (w#1 and w#2). Both instances connect to the same database.


      user #1 log on to w#1

      user #2 log on to w#2


      user #1 search for a list of hotels, and I can see the cacheable query was printed out in the console. User #1 continue to view the hotel (id = 1). No query was printed out. Note, this is using EntityManager.find(), and it is expected that the object was cached, so no query was printed out.


      user #2  did the same things, and the observation was same.


      User #1 edited the hotel object (id=1), the update statement was printed out. user #1 go back to search page and revisited the same hotel (id=1), no query was printed out. This is good since the latest update statement cached the result.


      User #2 visited the hotel object, and a query to find a single object was printed out. This was expected since the cache for the object was invalidated. However, when user #2 revisited the same object, the query got printed out again, and this happened until after a period of time (probably the configured expiration).


      The behavior indicates that the wildfly instance which actually made the modification of an object was able to cache the new data, but the wildfly instance (of the cluster) which received the signal to invalidate the cache did just that: invalidate the cache, but not create new cache for the latest data.


      Is this the intended design by infinispan? or if there is any other configuration I need to make?