Return-Path: Delivered-To: apmail-incubator-jspwiki-dev-archive@minotaur.apache.org Received: (qmail 2877 invoked from network); 25 Jul 2009 15:22:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Jul 2009 15:22:24 -0000 Received: (qmail 14830 invoked by uid 500); 25 Jul 2009 15:23:29 -0000 Delivered-To: apmail-incubator-jspwiki-dev-archive@incubator.apache.org Received: (qmail 14802 invoked by uid 500); 25 Jul 2009 15:23:29 -0000 Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jspwiki-dev@incubator.apache.org Delivered-To: mailing list jspwiki-dev@incubator.apache.org Received: (qmail 14792 invoked by uid 99); 25 Jul 2009 15:23:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Jul 2009 15:23:29 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of janne.jalkanen@ecyrd.com designates 193.64.5.122 as permitted sender) Received: from [193.64.5.122] (HELO mail.ecyrd.com) (193.64.5.122) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Jul 2009 15:23:18 +0000 Received: from [10.0.1.3] (dsl-roibrasgw1-ff9ac100-178.dhcp.inet.fi [88.193.154.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ecyrd.com (Postfix) with ESMTPSA id 7F9E697C1FE for ; Sat, 25 Jul 2009 18:22:53 +0300 (EEST) Message-Id: From: Janne Jalkanen To: jspwiki-dev@incubator.apache.org In-Reply-To: <72777D06-9F14-4E30-84CF-671B3A74874F@ecyrd.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Versioning now available Date: Sat, 25 Jul 2009 18:22:52 +0300 References: <377334CC-749F-43B8-B69A-7FBB34B608B4@gmail.com> <72777D06-9F14-4E30-84CF-671B3A74874F@ecyrd.com> X-Mailer: Apple Mail (2.935.3) X-Virus-Checked: Checked by ClamAV on apache.org >> * Could checkout() be made part of the page-locking process? Could >> the >> act of placing a PageLock prompt a checkout() operation? > > req's reworking of pagelocks; embedded use does not require locking. > They are conceptually different also, since pagelock can last for a > long time. Also, to continue in this vein, JCR also supports locking as a separate thing, and that's conceptually even more different than PageLocks. I haven't yet figured out a good use for the JCR locking in JSPWiki context. It has a couple of downsides: * JCR locks expire randomly. That is, most of the time they do not expire, but there is usually a cleanup process which randomly throws away old locks. JCR defines no way to configure this. * JCR lock tokens require a lot of safekeeping; if you lose one, you can't unlock. * JCR locks don't have the necessary metadata to replace PageLocks; those would need to be managed manually anyway. * PageLocks can be broken trivially programmatically; JCR locks cannot, unless you have the token. JCR locking is really meant to prevent concurrent modification by multiple accessors. I think we might find them very useful when we enable clustering, but before then I'm not too sure what to use them for. /Janne