You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by David Kennedy <da...@us.ibm.com> on 2006/06/27 17:11:49 UTC
Logging into a repository multiple times
Is a user permitted to login to the same repository/same workspace
multiple times? So they'll have multiple sessions.....If so, why are
lockTokens restricted to a single session? They are ineffective when
applied to a second session. What's the reason for this restriction?
David
Re: Logging into a repository multiple times
Posted by Marcel Reutegger <ma...@gmx.net>.
David Kennedy wrote:
> Marcel Reutegger <ma...@gmx.net> wrote on 06/27/2006 03:25:47
> PM:
>
>> David Kennedy wrote:
>>> Is a user permitted to login to the same repository/same workspace
>>> multiple times?
>> yes
>>
>>> So they'll have multiple sessions.....If so, why are
>>> lockTokens restricted to a single session? They are ineffective when
>>> applied to a second session. What's the reason for this restriction?
>> This restriction ensures that only one active session is holding a lock
>> and is able to modify the locked node.
>>
>
> Thanks. I understand the synchronization, but why is that necessary? It
> seems contradictory to the optimistic model of InvalidItemStateException
> in JSR 170.
The optimistic model only applies to nodes that are not locked. If a
node is locked and the current session is in possession of the lock
token, the session can be sure that no InvalidItemStateException will
occur. The repository ensures in that case that *no* other session (even
a session for the same user) is able to modify the node.
> Why couldn't an application be the decision point of whether
> multiple sessions can unlock the nodes, or even which sessions?
well, I guess in some cases this would also make sense, but the EG of
JSR 170 decided that this is not possible with a JCR repository...
> Isn't that the idea behind the lockTokens in the first place?
The idea is that only one session at a time can hold a certain lock
token and only that session can write to the locked node and unlock it.
regards
marcel
Re: Logging into a repository multiple times
Posted by David Kennedy <da...@us.ibm.com>.
Marcel Reutegger <ma...@gmx.net> wrote on 06/27/2006 03:25:47
PM:
> David Kennedy wrote:
> > Is a user permitted to login to the same repository/same workspace
> > multiple times?
>
> yes
>
> > So they'll have multiple sessions.....If so, why are
> > lockTokens restricted to a single session? They are ineffective when
> > applied to a second session. What's the reason for this restriction?
>
> This restriction ensures that only one active session is holding a lock
> and is able to modify the locked node.
>
Thanks. I understand the synchronization, but why is that necessary? It
seems contradictory to the optimistic model of InvalidItemStateException
in JSR 170. Why couldn't an application be the decision point of whether
multiple sessions can unlock the nodes, or even which sessions? Isn't
that the idea behind the lockTokens in the first place?
> regards
> marcel
Re: Logging into a repository multiple times
Posted by Marcel Reutegger <ma...@gmx.net>.
David Kennedy wrote:
> Is a user permitted to login to the same repository/same workspace
> multiple times?
yes
> So they'll have multiple sessions.....If so, why are
> lockTokens restricted to a single session? They are ineffective when
> applied to a second session. What's the reason for this restriction?
This restriction ensures that only one active session is holding a lock
and is able to modify the locked node.
regards
marcel