Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <15531033.163531294246485990.JavaMail.jira@thor>
Date: Wed, 5 Jan 2011 11:54:45 -0500 (EST)
From: =?utf-8?Q?C=C3=A9dric_Damioli_=28JIRA=29?= <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-2859) Make open scoped locks recoverable
In-Reply-To: <5100067.156451294219425338.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JCR-2859?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D129778=
38#action_12977838 ]=20

C=C3=A9dric Damioli commented on JCR-2859:
-------------------------------------

I tend to agree with Stefan that it's the client responsibility to store lo=
ck tockens.
It's the way I'm managing locks in my applications.

But it may happen some failures (either in the client code or in JR code) t=
hat make the tocken unrecoverable.

Giving the possibility to have some admin feature to cover such cases in IM=
HO a very good thing.
Right now, I have to stop the application (which may be very annoying in pr=
oduction) and modify the locks file by hand.

So a big +1 to Jukka's proposal, if client code is able to have access to s=
uch special sessions.


> Make open scoped locks recoverable
> ----------------------------------
>
>                 Key: JCR-2859
>                 URL: https://issues.apache.org/jira/browse/JCR-2859
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: locks
>    Affects Versions: 2.2.0
>            Reporter: Carsten Ziegeler
>
> The lock tokens for open scoped locks are currently tied to the session w=
hich created the lock. If the session dies (for whatever reason) there is n=
o way to recover the lock and unlock the node.
> There is a theoretical way of adding the lock token to another session, b=
ut in most cases the lock token is not available.
> Fortunately, the spec allows to relax this behaviour and I think it would=
 make sense to allow all sessions from the same user to unlock the node - t=
his is still in compliance with the spec but would make unlocked locked nod=
es possible in a programmatic way.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.