hibernate causing deadlocks in PostgresSql 8?

I'm having some deadlocks in my Postgres DB. I posted a question there and the only response I got indicated it was probably a hibernate-postgres issue.

Please take a look at:
and let me know if this really is likely to be a hibernate issue.

I can't debug the problems occuring on the server, but on my DB machine the one time it has occurred the problem is as follows:
- I'm using Hibernate 3 with PostgresSQL 8.
- I ran an app that launches up to 20 simultaneous threads to import some data into the DB. Intuitively this seems a likely source of the original deadlock, but this app has never been run on the public server, so if it's a source of problems then it's not the cause of the deadlocks on the public server.
- I later noticed that going to a particular page never returns. This is the same symptom I see on the public server.
- When I trace it on my local machine I find that it reaches a point in the code where it does a DB update and then it just stops.
- When I check Postgres I see that each new hit to that page causes a new process to wait on a particular lock. If you look in the info in the other page I linked to above, you'll see that for some reason all new inserts are part of the same transaction.
- Note that going to that page should not actually cause any updates. It looks to me like it's trying to finish an update that hibernate has queued up. That idea would fit with the idea that all the updates are part of the same transaction.

I apologize if that description is hazy. I really have little idea about what is going on. I don't want to restart the app server on my dev machine until I figure this out, so I'd appreciate any help anyone can give.

If anyone can determine from this info and the info on the other page if this is actually a postgres issue or a hibernate issue or both then I would be very grateful.
Who is Participating?
aozarovConnect With a Mentor Commented:
>> Is it possible that ehcache overflowed to disk an update to ..
Don't know what triggers your cache service (ehcache) to flush (probably not enough memory due to the global caching strategy)
but it is very likely to be the cause of the problem.
Try to disable disk flushing: (I think by setting the property overflowToDisk to false but not sure about that).
You can also post this question to ehcache forum: https://sourceforge.net/forum/forum.php?forum_id=322278
You can try also a different second level cache library (one that will not flush to disk).
See Hibernate documetion for other alternatives: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#performance-cache

Applying updates by different sessions/transactions can explain the dead-lock problem if the order of the flush is not deterministic.
HappyEngineerAuthor Commented:
Ok, I think this was an issue caused by ehcache somehow.

Since no one answered my question here I just went ahead and killed the webapp. I then started it again and displayed the page and it displayed fine. I hit refresh once and once again it locked up. I checked the DB and did some debugging and it looked like this was exactly the same issue it was before.

So, I restarted the app server again. This time hitting refresh once didn't lock it up. I hit refresh a few more times and still no lockup. I then held down ctrl-r to force a bunch of refreshes and lo and behold it locked up!

After debugging and finding it to be identical, I restarted and did a bunch of additional testing to figure out what the deal was.

The lockup occurs when it attempts to update a particular object in the database. However, as far as I can tell, there ARE NO UPDATES caused by viewing that page. It doesn't do anything that would change the object. I put breakpoints on all the save methods and none were called.

Here's the place where I nailed it down. I removed the
  <cache usage="read-write"/>
from the hbm for the problematic object type.

I then restarted and held down refresh and was no longer able to replicate this problem. I put the caching line back in the hbm and restarted and am still not able to replicate the problem.

So the upshot is that somehow the caching caused this issue.

Any theories?

I used to have caches specified for each object, but I ended up giving up trying to manage them and just went back to having one large cache using:


Is it possible that ehcache overflowed to disk an update to an object which it attempted to save every time I restarted the app server? If so then that explains the presence of the update, but it doesn't explain why the update never completed successfully.
HappyEngineerAuthor Commented:
I figured out the cause of the unexpected updates. I'll have to do tests to determine if updates cause deadlocks when they're done on purpose by my own code.

for the answer to why unexpected updates were occurring.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.