[ https://issues.apache.org/jira/browse/JCR-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474277#comment-13474277 ]
Bart van der Schans commented on JCR-3440: ------------------------------------------ >From the patch: To me the check "stopRevision != startRevision" looks unnecessary. If there are no records to consume then the stopRevision will still be at Long.MIN_VALUE. Also strangely enough the syncAgainOnNewRecords() functionality only seems to be only available in the 2.4 branch. > Deadlock on LOCAL_REVISION table in clustering environment > ---------------------------------------------------------- > > Key: JCR-3440 > URL: https://issues.apache.org/jira/browse/JCR-3440 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: clustering > Affects Versions: 2.4.3 > Environment: Env.1: 4x Linux server CentOS 5 MSSQL 2008 database > (production system) > Env.2: 2x Linux Ubuntu 10.04 server tested with PostgreSQL 9.1, H2, MSSQL > 2008 and mySQL 5.5 (lab system) > Reporter: Luca Tagliani > Priority: Critical > Attachments: JCR-3440.patch > > > 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 message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira