Hibernate version: 3.1.2
Database: PostgreSQL 8.1.2
Second-level cache: JBossCache 1.2.4 SP1
Hi!
We noticed a very unexpected and wrong behavior of second-level cache. This could also be a bug in JBossCache, but anyhow, the problem is very serious.
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:
Code:
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 JDBC transactions 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.
Thanks and regards,
Jaka
Login
FAQ
Search