Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Fri, 12 Oct 2012 07:57:03 +0000 (UTC)
From: "Bart van der Schans (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <236694071.36462.1350028623913.JavaMail.jiratomcat@arcas>
In-Reply-To: <1853128617.18711.1349854742873.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (JCR-3440) Deadlock on LOCAL_REVISION table in
 clustering environment
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474870#comment-13474870 ] 

Bart van der Schans commented on JCR-3440:
------------------------------------------

Hi Luca,

Usually patches are provided against trunk, but it isn't an issue if that particular code hasn't changed much.

For the syncAgainOnNewRecords() method is was just wondering why it is missing in trunk (on purpose?). Maybe somebody can elaborate on that although it's a bit off topic here.

Do you have the thread dumps? I'm still curious why there is a deadlock at all. My suspicion (like Clause's) is still that the deadlock might be caused by something else.

Bart
                
> 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