Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 17017 invoked from network); 30 May 2006 13:56:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 30 May 2006 13:56:48 -0000 Received: (qmail 68411 invoked by uid 500); 30 May 2006 13:56:46 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 68348 invoked by uid 500); 30 May 2006 13:56:45 -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 68154 invoked by uid 99); 30 May 2006 13:56:45 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 May 2006 06:56:43 -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 jukka.zitting@gmail.com designates 64.233.184.230 as permitted sender) Received: from [64.233.184.230] (HELO wr-out-0506.google.com) (64.233.184.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 May 2006 06:56:41 -0700 Received: by wr-out-0506.google.com with SMTP id i7so1106033wra for ; Tue, 30 May 2006 06:56:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CRxMkiZ+ESjq67gMNA/4NdCQ/MK8MXIqlduKE1Qqt8S1Wtu3PV4lCtDfTYZkGdNYGRlFKQ3DGCVc1lpfUtby+T66DulNCYOaooDABGm0Mr0Y6LVCQpyAC8pKcWYd0xerfyXD17G4iQQeILpN0ghP+vIx35pEz373EGeg6iUI2z0= Received: by 10.54.128.3 with SMTP id a3mr300117wrd; Tue, 30 May 2006 06:56:15 -0700 (PDT) Received: by 10.54.117.10 with HTTP; Tue, 30 May 2006 06:56:15 -0700 (PDT) Message-ID: <510143ac0605300656j393e9728u9ec4ae7db6b33a71@mail.gmail.com> Date: Tue, 30 May 2006 16:56:15 +0300 From: "Jukka Zitting" To: dev@jackrabbit.apache.org Subject: Re: Google Summer of Code project for Jackrabbit In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi, On 5/30/06, David Kennedy wrote: > Just to continue the lock discussion....I don't think jcr:Locks are an > issue on the backup operation, however they are an issue on the restore. > What will happen on a restore when a lock is held on a node being > restored? Will the node be replaced, the lock reapplied and the isms > updated so InvalidItemStateExceptions will be thrown on any subsequent > saves prior to a re-get? I think that we can safely limit the scope of the restore operation to an empty workspace or repository for now, thus avoiding all problems associated to merging with existing content. We can also scope out any concurrent sessions for the restore operation, so there is no need to send observation events for the restored content. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - info@yukatan.fi Software craftsmanship, JCR consulting, and Java development