Hi!
We are using JBossCache with Hibernate and we noticed a very unexpected and wrong cache behavior. This could also be a bug in Hibernate, but anyhow, the problem is very serious and I would very much appreciate any information.
The thing is that changed data remains in the second-level cache even if the changes are not successfully flushed into the database, or if the transaction has been explicitly rolled-back.
Here is one simple way to reproduce the problem:
SomeObject o = session.get(SomeObject.class, 1);
o.setSomeProperty("a value too long for the DB field"); // to trigger exception
session.flush();A DataException occurs during the flush() call, so nothing is committed into the database, but the change remains in the L2 cache. So the next time I open a session and get() the object, it has someProperty set to "a value too long for the DB field". How can this happen?! Why are the changes not stored in the L2 cache only affter a successful commit into the database?
I thought using transactions would solve the problem, but it does not. A rollback does not roll back data in L2 cache. And the same thing happens if I do a rollback after a successful flush - the change in the database is rolled back, but it remains in L2 cache....
Could we be doing something wrong here? We are using Hibernate 3.1.2 with JDBC transactions, JBossCache 1.2.4 SP1, PostgreSQL 8.1.2 and the class-cache is set to transactional.
Please help. This is a very serious problem and I see no way to solve it other than to disable (or perhaps replace) the L2 cache, which we really don't want.
If this is a Hibernate problem, please let me know.
Thanks and regards,
Jaka
