-
Bug
-
Resolution: Obsolete
-
Blocker
-
None
-
11.0.11.Final, 12.1.7.Final
-
None
-
wf23-2ndlevelcache-problem-minimal.zip
Attached is a reproduction environment in a WildFly setup. To run the reproduction scenario Docker and Maven is required. A step by step instruction is given in the included README.MD. Please note that in this setup it takes quite some time to reproduce this bug behavior. However, the test will eventually fail! We keep working on a better reproduction environment where the bug can be reproduced more easily. Please contact me if further instructions for the reproduction scenario are required.
wf23-2ndlevelcache-problem-minimal.zip Attached is a reproduction environment in a WildFly setup. To run the reproduction scenario Docker and Maven is required. A step by step instruction is given in the included README.MD. Please note that in this setup it takes quite some time to reproduce this bug behavior. However, the test will eventually fail! We keep working on a better reproduction environment where the bug can be reproduced more easily. Please contact me if further instructions for the reproduction scenario are required.
We are running a WildFly application where we use the Hibernate second level cache. After our update from WildFly10 to WildFly23 we encountered serious problems with the second level cache:
In rare cases, we encountered a lost-update problem: The entity in the second level cache is not updated and is out of sync with the database. In our setup we rely havily on Hibernate's optimistic locking feature. A stale entity can therefore no longer be updated.
Even though the cases where we encountered this problem are rare, it led to affected production systems at least once a week which forced us to rollback to the old WildFly version. At first we thought it must be a configuration problem or implementation bug on our side, but we spent several months now and have identified that the underlying pending-puts cache seems to be responsible. When we reduce the expiration of the pending-puts cache to 5 seconds, the bug is very easily reproducible in our applications reproduction scenario. When we increase the expiration to 300 seconds, we were not able to reproduce the bug in our scenario. With this finding we went further and created an plain WildFly application where we can reproduce the bug, see steps to reproduce for further details.
