Ok, it is more clear now (it is still not clear how exactly thread 5
locks that PostgreSQL table, but the overall explanation makes sense).
One suggestion is to upgrade to Cayenne 3.0 (3.0M3 for now, and 3.0M4
once that becomes available). It reduces the scope of the shared
DataRowStore lock per this Jira:
https://issues.apache.org/cayenne/browse/CAY-722
Alternatively you may attempt to patch 1.2 based on CAY-722 diff:
http://tinyurl.com/56ja5r
Andrus
On May 16, 2008, at 3:08 AM, Martin Thelian wrote:
Hi!
Andrus Adamchik schrieb:
Hmm... I don't see a deadlock, just a contention with other threads
waiting for "userDataBeanMessageListener-5" to finish commit. So does
it result in slowness or a complete deadlock?
It's not just slow, these threads completely bock each other. The
first
thread userDataBeanMessageListener-5 can not finish it's commit
because
it seems to be waiting for the DB to release a lock to a table the
other
thread is accessing. And the second thread
userDataBeanMessageListener-1
can not finish its query because of the synchronized block it can
not enter.
The only thing I can do if this problem occurs is to kill the runtime
and start it again.
(there are known issues with nested contexts [1], but there weren't
any with the top-level contexts in a while).
No we don't use nested context. But we are using transaction.
Regards,
Martin
