Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-24628

[GSS](7.4.z) HHH-13627 - Hibernate cache invalidation does not happen

    XMLWordPrintable

Details

    • False
    • None
    • False
    • Hide

      I used Postgres database to recreate the issue. The SQL file is include in the project root directory to create database tables.
      Steps to reproduce:
      1. Unzip the archive and build it using Maven
      2. Create a database schema and execute the script createDB.sql (we are using Oracle 19)
      3. Prepare a virgin JBoss 7.3.9 with an Oracle JDBC driver
      4. Copy the provided standalone.xml into the configuration folder and adjust the database connection
      5. Deploy the built WAR and start the JBoss
      6. Using a tool like Postman, call the following REST APIs:
      6.1. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/persons/100
      -> this is to load the person into the cache
      6.2. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/phones/200
      -> this is to load the phone into the cache
      6.3. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/phones/attach
      -> this attaches the phone to the person - you can check this in the database
      -> but does not update the phone in the cache nor remove it from the cache!!!
      6.4. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/phones/200
      -> you'll see that the returned data still show an unattached phone
      6.5. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/persons/100
      -> but you'll see here that the person has the phone all right
      6.6. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/clearCache
      -> this is to clear the 2nd-level-cache
      6.7. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/phones/200
      -> suddenly the phone is attached to the person

      Show
      I used Postgres database to recreate the issue. The SQL file is include in the project root directory to create database tables. Steps to reproduce: 1. Unzip the archive and build it using Maven 2. Create a database schema and execute the script createDB.sql (we are using Oracle 19) 3. Prepare a virgin JBoss 7.3.9 with an Oracle JDBC driver 4. Copy the provided standalone.xml into the configuration folder and adjust the database connection 5. Deploy the built WAR and start the JBoss 6. Using a tool like Postman, call the following REST APIs: 6.1. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/persons/100 -> this is to load the person into the cache 6.2. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/phones/200 -> this is to load the phone into the cache 6.3. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/phones/attach -> this attaches the phone to the person - you can check this in the database -> but does not update the phone in the cache nor remove it from the cache!!! 6.4. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/phones/200 -> you'll see that the returned data still show an unattached phone 6.5. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/persons/100 -> but you'll see here that the person has the phone all right 6.6. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/clearCache -> this is to clear the 2nd-level-cache 6.7. localhost:8080/cacheissue-1.0-SNAPSHOT/api/inconsistency/phones/200 -> suddenly the phone is attached to the person
    • Critical

    Description

      According to the Hibernate documentation the cache mode GET is defined like this: "The session may read items from the cache, but will not add items, except to invalidate items when updates occur."

      The problem is that these invalidations don't happen. The background tasks not only create a lot of entities but also change some of them. So the failing cache invalidation leads to an inconsistent cache state. We got a lot of complaints from users that after such a background task ran, the information they see in their apps are incorrect. But on the other hand we can not refrain from changing the cache mode, since this will lead to performance issues.

      Attachments

        Issue Links

          Activity

            People

              chaowan@redhat.com Chao Wang
              rhn-support-toross Tom Ross
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: