Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 21461 invoked from network); 21 Oct 2005 11:42:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Oct 2005 11:42:32 -0000 Received: (qmail 5051 invoked by uid 500); 21 Oct 2005 11:42:31 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 5040 invoked by uid 99); 21 Oct 2005 11:42:31 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Oct 2005 04:42:31 -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 Oct 2005 04:42:30 -0700 Received: (qmail invoked by alias); 21 Oct 2005 11:42:07 -0000 Received: from adsl-84-226-114-63.adslplus.ch (EHLO [192.168.0.101]) [84.226.114.63] by mail.gmx.net (mp001) with SMTP; 21 Oct 2005 13:42:07 +0200 X-Authenticated: #894343 Message-ID: <4358D40D.6060006@gmx.net> Date: Fri, 21 Oct 2005 13:42:05 +0200 From: Marcel Reutegger User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jackrabbit-dev@incubator.apache.org Subject: Re: Multithreading/Mutliuser(?) access References: <20051020114011.GA17016@jdevoff.zssm.zp.ua> <20051020122055.GE17016@jdevoff.zssm.zp.ua> <4357A197.30602@gmx.net> <20051020140937.GD78211@jdevoff.zssm.zp.ua> <4357B777.4090803@gmx.net> <20051021092636.GB1246@jdevoff.zssm.zp.ua> <4358B7C2.50109@gmx.net> <20051021103021.GF1246@jdevoff.zssm.zp.ua> In-Reply-To: <20051021103021.GF1246@jdevoff.zssm.zp.ua> Content-Type: text/plain; charset=KOI8-R; 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 Eugeny N Dzhurinsky wrote: > Actually my question is : how can I access the same node from several sessions > and threads w/o breaking things? simply use a separate session for each thread that writes to the workspace. and you will be fine. keep in mind that jcr operations on a read-committed basis talking in database terms. if you required a higher isolation level you need to use locks. > I just need to know caveats before we will > start implementing our CMS with JackRabbit. I wrote test application which > emulates concurrent access to the same node, and all what I'm getting now - > just set of exceptions, which identifies I should take care of synchronising > between sessions by myself, but I don't see any way to do that w/o > hacking/modifying JackRabbit code, am I correct? that's definitively something you shouldn't do, though we are always happy to accept patches that improve jackrabbit. but in this case the exceptions you see are because the jcr specification says so. again, use locks if you want to be sure that no other session modifies nodes that you are trying to commit. otherwise be prepared that a save() might fail. regards marcel