[ https://issues.apache.org/jira/browse/JCR-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-3738: ------------------------------- Assignee: (was: Jukka Zitting) So far I couldn't find any clear reasons for why this would happen. One possible lead is that this might have something to do with the way ConnectionHelper uses the TransactionContext.getCurrentThreadId() to share a connection across threads when they're linked into the same transaction. There's a workaround in configuring the database backend to timeout blocked statements. It breaks this deadlock, so a partial solution (that doesn't fix the root cause) might be to try using Statement.setQueryTimeout() in DatabaseJournal.doLock(). > CLONE - Deadlock on LOCAL_REVISION table in clustering environment > ------------------------------------------------------------------ > > Key: JCR-3738 > URL: https://issues.apache.org/jira/browse/JCR-3738 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: clustering > Affects Versions: 2.6.2 > Environment: CQ5.6.1 with jackrabbit-core 2.6.2 backed off ibm db2 > v10.5 > Reporter: Ankush Malhotra > Priority: Critical > Attachments: before-lock.zip, db-deadlock-info.txt, stat-cache.log, > threaddumps.zip > > > Original, cloned description: > > When inserting a lot of nodes concurrently (100/200 threads) the system > > hangs generating a deadlock on the LOCAL_REVISION table. > > There is a thread that starts a transaction but the transaction remains > > open, while another thread tries to acquire the lock on the table. > > This actually happen even if there is only a server up but configured in > > cluster mode. > > I found that in AbstractJournal, we try to write the LOCAL_REVISION even if > > we don't sync any record because they're generated by the same journal of > > the thread running. > > > > Removing this unnecessary (to me :-) ) write to the LOCAL_REVISION table, > > remove the deadlock. > This might not be the exact same case with this issue. See the attached > thread dumps etc. for full details. -- This message was sent by Atlassian JIRA (v6.2#6252)