Re: Deadlock between commitChanges and snapshotsUpdatedForObjects

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri May 16 2008 - 07:45:49 EDT

  • Next message: Andrus Adamchik: "Re: Deadlock between commitChanges and snapshotsUpdatedForObjects"

    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
    >

    This archive was generated by hypermail 2.0.0 : Fri May 16 2008 - 07:46:27 EDT