Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 41885 invoked from network); 21 Apr 2006 14:40:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Apr 2006 14:40:30 -0000 Received: (qmail 88307 invoked by uid 500); 21 Apr 2006 14:40:18 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 88236 invoked by uid 500); 21 Apr 2006 14:40:16 -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 88211 invoked by uid 99); 21 Apr 2006 14:40:16 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Apr 2006 07:40:16 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.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; Fri, 21 Apr 2006 07:40:15 -0700 Received: (qmail invoked by alias); 21 Apr 2006 14:39:53 -0000 Received: from bsl-rtr.day.com (EHLO [10.0.0.70]) [212.249.34.130] by mail.gmx.net (mp027) with SMTP; 21 Apr 2006 16:39:53 +0200 X-Authenticated: #894343 Message-ID: <4448EEB6.5080304@gmx.net> Date: Fri, 21 Apr 2006 16:39:50 +0200 From: Marcel Reutegger User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: Concurrent modifications ... References: <758c12420604200353v592999acl1260ab48b2866981@mail.gmail.com> <44477252.1010706@gmx.net> <758c12420604200514n3115b065p85b38be7f6e634a4@mail.gmail.com> <758c12420604210626gb30c88fnb533da48ab926b6a@mail.gmail.com> In-Reply-To: <758c12420604210626gb30c88fnb533da48ab926b6a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Robert Shiner wrote: > Yup, that seems to work, thanks. Although not against 1.0, I needed to > checkout and build the latest snapshot. oh, you are right. thanks for pointing that out. the related issue is: JCR-336. > Does anyone know when the next release with the lock fixes in is due? > > Also I have a question around applying the lockable mixin. > > I understand that a node can not be locked unless it has the lockable mixin > applied. IMO a good node type design already has the mix:lockable mixin in its definition for nodes that should be lockable. with such a design it is then not necessary for an application to add mixins on node instances. > If I want to lock a node, but I'm not sure whether it already has > the lockable mixin, how can I check and then add the mixin in such a way > that is safe in a concurrent environment? node.isNodeType("mix:lockable") will return true if it is lockable. you need to aquire a deep lock on a lockable ancestor of that node then you can add a mixin to the desired node. but as I pointed out before I suggest you do not add mixins to individual node instances but define lockable mixins in your type hierarchy. regards marcel