jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@day.com>
Subject Re: Ceckin/-out, Locking - Description and tests missing in the Spec/TCK
Date Mon, 02 Nov 2009 14:32:42 GMT
On Mon, Nov 2, 2009 at 1:14 PM, Alexander Klimetschek <aklimets@day.com> wrote:
> On Sat, Oct 31, 2009 at 19:15, Daniel Manzke
> <daniel.manzke@googlemail.com> wrote:
>> My questions:
>> Is checkin/-out user based?
>> So that this is the checkin/-out like described in my example?
> No, it's not user based. It is not the same as a checkout in svn for
> example, since all it does is make the "head" of the versioned node
> writable, but this is just one checkout as opposed to many remote
> checkouts to local workspaces as in svn.
>> Is checkin/out only for creating a new version?
>> This would mean, then my user checks in his document, I have to checkout the
>> node, add the new property and then checkin?
> Right.
>> I thought about using the open-scoped Lock for a long time checkout. Does a
>> user can change properties, when he locked a document?
> Yes, a lock is either per-session (session-scoped lock) or per user,
> which is recorded in the jcr:lockOwner property in a lock.
this is partially true. the locking is always independent of the user
performing the lock. session-scoped locks cannot be transferred to
other sessions and only the locking session can update and unlock.

for open-scoped locks, the users has no impact of the locking,
neither. in order to transfer a lock-membership, you need to augment
the respective session with the lock token. further, you need to
remember the lock-token yourself, if you wish at a later point in time
to update or unlock the node.

in jackrabbit 2.0 you can implement easily a own lock manager that
offers different locking mechanisms. for example you could allow
update and unlock if the session's user is the lock owner. see:


regards, toby
>> I didn't saw any
>> testcase or description in the spec, how this should work.
> Both JCR 1.0 (section 8.4 [1]) and JCR 2.0 (section 17 [2]) IMO give a
> short and precise description: "In those repositories that support it,
> locking allows a user to temporarily lock nodes in order to prevent
> *other* users from changing them." (emphasis added)
> I think an example together with versioning is not included as locking
> is generic and might not necessarily be used to avoid checkin's from
> other users.
>> I would prefer this way:
>> - a user locks a document (Node.lock(..))
>> - if it is versionable he checks it out (Node.checkout(..))
>> - do his stuff
>> - save (Node.save(..))
>> - checks in (Node.checkin(..))
>> - unlock (Node.unlock(..))
>> Is this possible?
> Yes.
> [1] http://www.day.com/specs/jcr/1.0/8.4_Locking.html
> [2] http://www.day.com/specs/jcr/2.0/17_Locking.html
> Regards,
> Alex
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com

View raw message