From users-return-18559-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Mon Feb 6 17:02:03 2012 Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7BD4D9CFF for ; Mon, 6 Feb 2012 17:02:03 +0000 (UTC) Received: (qmail 87944 invoked by uid 500); 6 Feb 2012 17:02:02 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 87884 invoked by uid 500); 6 Feb 2012 17:02:02 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 87876 invoked by uid 99); 6 Feb 2012 17:02:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2012 17:02:01 +0000 X-ASF-Spam-Status: No, hits=1.3 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mslama@email.cz designates 77.75.72.26 as permitted sender) Received: from [77.75.72.26] (HELO mxh1.seznam.cz) (77.75.72.26) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2012 17:01:55 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=email.cz; h=In-Reply-To:Received:Date:Reply-To:To:From:Subject:Mime-Version:Message-Id:Content-Transfer-Encoding:Content-Type:X-Country:X-Abuse:X-Seznam-User:X-Virus-Info:X-Seznam-SPF:X-Seznam-DomainKeys; b=Aqg6VrF3ENCuruvYPf/qUSzZe/W/ja/+x/Eb+JDTEUyXGViOdmLUVTo3/bfFu2rnp /fmBtqaO40YCo59znvo6sAMuql0p5gNJX0+a/lUu3mILRdTGTSFLFig7NTdK+3SkBcD 01IiP2umlUHuDSkDW9Ey7eLRTZGt0LeamO3O7do= In-Reply-To: <1328544988129-4361768.post@n4.nabble.com> Received: from ( [80.188.171.66]) by email.seznam.cz (Email.Seznam.cz) with HTTP for mslama@email.cz; Mon, 6 Feb 2012 17:26:44 +0100 (CET) Date: Mon, 06 Feb 2012 18:01:33 +0100 (CET) Reply-To: mslama@email.cz To: users@jackrabbit.apache.org From: mslama@email.cz Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Re=3A=20Re=3A=20Any=20way=20how=20to=20remove=20node=20lock=3F?= Mime-Version: 1.0 Message-Id: <98899.1333.2109-14500-804510901-1328547693@email.cz> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-2" X-Country: -- X-Abuse: abuse@seznam.cz X-Seznam-User: mslama@email.cz X-Virus-Info:clean X-Seznam-SPF:neutral X-Seznam-DomainKeys:neutral X-Virus-Checked: Checked by ClamAV on apache.org I found another problem with transferring lock token between sessions: Lock lock =3D null; Session session; session =3D sessionFactory.newSession(); try { lock =3D tryLockNode(session, companyPath); logger.debug("LockToken:" + lock.getLockToken()); session.save(); } finally { session.logout(); } session =3D sessionFactory.newSession(); LockManager lockManager =3D null; try { if (lock !=3D null) { lockManager =3D session.getWorkspace().getLockManager()= ; lockManager.addLockToken(lock.getLockToken()); } return doUpdateCompany(session, company, sendMessage, conta= inerId, companyPath); } finally { if (lockManager !=3D null) { lockManager.unlock(companyPath); } session.logout(); } with this code I still get Caused by: javax.jcr.lock.LockException: Nod= e not locked by session: 8dc7ae65-fc46-46d7-a73b-5077808edbef =09at org.apache.jackrabbit.core.lock.LockManagerImpl.checkUnlock(LockM= anagerImpl.java:773) [jackrabbit-core-2.2.9-noLogs.jar:] =09at org.apache.jackrabbit.core.lock.LockManagerImpl.checkUnlock(LockM= anagerImpl.java:754) [jackrabbit-core-2.2.9-noLogs.jar:] =09at org.apache.jackrabbit.core.lock.XALockManager.checkUnlock(XALockM= anager.java:207) [jackrabbit-core-2.2.9-noLogs.jar:] =09at org.apache.jackrabbit.core.lock.SessionLockManager.unlock(Session= LockManager.java:202) [jackrabbit-core-2.2.9-noLogs.jar:] .... when lockManager.unlock(companyPath); So it looks like transfering lock token between sessions does not work = as I expected. To get lock I use: lock =3D lockManager.lock(nodePath, false, false, Long.MAX_VALUE, ""); For now I give up using JCR node locking. As I said before I assumed I must use separate session to lock node so = that another sessions will see this lock in my JBoss env with XATransaction support. I checked LockerManagerImpl.checkUnlock and its javadoc says: Default implementation allows unlocking to the lock holder only. I am looking at Jackrabbit sources now to see if I find anything. Marek > ------------ P=F9vodn=ED zpr=E1va ------------ > Od: Mark Herman > P=F8edm=ECt: Re: Re: Re: Any way how to remove node lock? > Datum: 06.2.2012 17:17:01 > ---------------------------------------- > I tried using locks for my application, but ultimately had to take th= em out. > Using admin seemed to solve my problems, but it was not an option to = hard > code admin credentials to create new sessions when needed to address = them. > > Locks in Jackrabbit seem a bit too "serious" (perhaps not JR's fault = but > JCR). It would be nice if you could at least grant access to overrid= e locks > without a lock token. > > For my application I eventually stopped using locking and implemented= the > functionality i needed in my layer above JR. Luckily for me, that is= a > single java api so it was pretty easy, maybe it's an option for you. = > > -- > View this message in context: > http://jackrabbit.510166.n4.nabble.com/Any-way-how-to-remove-node-loc= k-tp4361516p4361768.html > Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > > > Marek Slama mslama@email.cz