Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 32316 invoked from network); 14 Mar 2007 13:25:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Mar 2007 13:25:58 -0000 Received: (qmail 86335 invoked by uid 500); 14 Mar 2007 13:26:04 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 86307 invoked by uid 500); 14 Mar 2007 13:26:04 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 86298 invoked by uid 99); 14 Mar 2007 13:26:04 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Mar 2007 06:26:04 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of marcel.reutegger@gmx.net designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 14 Mar 2007 06:25:53 -0700 Received: (qmail invoked by alias); 14 Mar 2007 13:25:31 -0000 Received: from bsl-rtr.day.com (EHLO [10.0.0.110]) [62.192.10.254] by mail.gmx.net (mp019) with SMTP; 14 Mar 2007 14:25:31 +0100 X-Authenticated: #894343 X-Provags-ID: V01U2FsdGVkX19uW2ghZm5ut/EtvvDld3NSkbl+XDHH/butZ5kgmf CZCzgSsrkBz0KD Message-ID: <45F7F7C9.7030802@gmx.net> Date: Wed, 14 Mar 2007 14:25:29 +0100 From: Marcel Reutegger User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: Possible deadlock of jcr-server 1.2.1 (rmi) References: <45F7B6AD.70101@gmx.net> <510143ac0703140155r54caaf58h7cfc17500bdd36e4@mail.gmail.com> <9f929f1c0703140339m7d12ca6lbb1f8d865cc6fe6e@mail.gmail.com> <8be731880703140357g19b06745h2a7fd53eaa47a868@mail.gmail.com> <510143ac0703140409p565dec1cg175c3c818e9bea15@mail.gmail.com> In-Reply-To: <510143ac0703140409p565dec1cg175c3c818e9bea15@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org Jukka Zitting wrote: > Do we have some directions that seem worth pursuing? Would rethinking > the locking mechanisms be enough, or do we need to fundamentally > modify the basic ItemStateManager and VersionManager designs? I haven't thought about this in much detail, but IMO the sequence how locks are acquired is the most problematic part of this issue. If we can ensure that locks are always acquired in the same sequence a deadlock shouldn't occur that easily. Here's what I've been thinking about: - Add a check to the SharedItemStateManager (SISM) if it has VirtualItemStateProvider (VISP). This will be the case for the workspace SISM, but not for the SISM in the version manager. Furthermore if the change log contains references into one of the VISPs, those VISPs must be write locked *before* this SISM is write locked. Otherwise only this SISM needs to be locked. This should ensure that the lock sequence is always: VISP and then SISM. I'm not sure about the lock in AbstractVersionManager (AVM), but since the AVM is on a higher layer than the VISP the overall lock sequence should be: AVM, VISP then SISM. Thoughts? regards marcel