Delete not always executing


This case I just ran into works in 3.1.3 but fails in 3.2.0 Release Candidates (1-4).

In a single JTA transaction I execute unit test:, lastName, email, phone, password);
Person person = personManager.get(email); // Not the PK
personManager.delete(person); // Deletes by PK
person = personManager.get(email); // Not the PK

personManager is just a DAO that uses a Spring HibernateTemplate to call save/delete/get on the underlying Session.

In 3.1.3, the final "assertNull(person)" succeeds.
In 3.2-RC4 it fails

Also, if I replace that final get with:
person = personManager.get(person.getId()); // Get by PK

Then the assertion succeeds.

When I turn on logging for org.hibernate.SQL, I can see in 3.2-RC4 the delete is never executed (unlike in 3.1.3). If I had to make a total guess, I would suspect that in 3.2-RC4 the delete it only getting applied to the session cache, and never making it to the database for some reason. Then, since the get(email) is not by primary key, it skips the cache (where it has been removed) and finds it still in the database.

Sorry I am unable to give you a discrete case you can run to reproduce this issue (there are a stupid number of dependencies), but hopefully this case will trigger a lightbulb to go off for the developer who was last working in this portion of the code.


MySQL (latest stable), XP/Linux, hibernate 3.2.0.cr4, Spring 2.0-rc3


Steve Ebersole
September 8, 2006, 4:36 PM

I tend to cast a curious eye on bug reports referencing user DAO classes, especially Spring HibernateTemplate based DAOs which have a well documented history of issues with Hibernate interaction.

Sorry, but if you cant be bothered to create a simplified test case, then I cant be bothered dealing with this issue. Look creating these simplified test cases serves 3 desireable purposes:
1) Forces you to isolate the problem and verify that it is indeed an issue with Hibernate (that is after all the point of a bug report);
2) Gives us (the developers) an way to reproduce the issue;
3) Gives us (the developers) a way to verify a fix and make sure we do not later instroduce a regression against it.

Jasper Rosenberg
October 5, 2006, 1:39 PM

Look, I'm sure you are burnt out on clueless users, but that is no reason to be rude.

Yes, I know it is unfortunate that I haven't produced a simple test case. I work on the Quartz project and I know how these kind of reports are super crappy.

However, rather than dwell on what you don't have, perhaps you should be happy for what you do have, an early warning of a 3.2/3.1 regression issue!

After all, when all things are held constant other than the version of Hibernate, it should be a pretty big red flag that something changed in 3.2 to cause the underlying issue. Even if it is some false assumption in Spring or Jotm or whatever, it would still be hibernate 3.2 that changed the behavior of the implicit contract and that is something you would want to research and document for a new release at the very least.

I will spend some time this morning to see if I can produce a test case (because you asked so nicely but even if you don't hear from me again, I would suggest thinking through the case where in the same transaction someone saves an object, deletes the object, and then tries to retrieve it by its non-PK, and why in this case hibernate doesn't realize it has to have executed the delete sql before the retrieval (though it does work correctly if it is a retrieval by PK). I'm sure you must know exactly where in the code the determination is made about whether to execute pending sql, and can look to see if something has changed since 3.1 to no longer execute a pending delete in the face of a retrieval by non-pk.

Best of luck!

Jasper Rosenberg
October 5, 2006, 2:45 PM


So I tried to reproduce this issue so I could hopefully reduce it to a simple test case and, of course, I can no longer do so. Our architecture has changed quite a bit since my original post, noteably we aren't using JTA transactions anymore and we changed the transaction isolation level from the default value of TRANSACTION_REPEATABLE_READ to TRANSACTION_READ_COMMITTED. Sorry I couldn't be more help!

Good luck!

Steve Ebersole
March 21, 2011, 7:06 PM

Bulk closing stale resolved issues




Jasper Rosenberg

Fix versions






Suitable for new contributors


Requires Release Note


Pull Request





Affects versions