Ceckin/-out, Locking - Description and tests missing in the Spec/TCK

[Daniel Manzke <da...@googlemail.com>]

Hi,

another time I studied the specification and didn't find an answer. This
time it's about checkin/-out and locking. I have a web application (and a
backend) which is using the JCR (until now 1.0 and ACLs from 2.0).
It's working quite well and some features are really nice, but I'm a little
bit confused how locking and checkin/-out should work.

In my case the application works with documents, where it could be that
several people are working on the same one. So I want that the users can
checkout a document. So this means for me, that the document is "locked"
until the document is checked in again and nobody without him can change
it.
So there are several ways how I think it could work.

My questions:
Is checkin/-out user based?
So that this is the checkin/-out like described in my example?

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?

I thought about using the open-scoped Lock for a long time checkout. Does a
user can change properties, when he locked a document? I didn't saw any
testcase or description in the spec, how this should work.

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?

Any ideas? Hints? Solutions?


Thanks and best regards,
Daniel

Re: Ceckin/-out, Locking - Description and tests missing in the Spec/TCK

[Tobias Bocanegra <tr...@day.com>]

On Mon, Nov 2, 2009 at 1:14 PM, Alexander Klimetschek <ak...@day.com> wrote:
> On Sat, Oct 31, 2009 at 19:15, Daniel Manzke
> <da...@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:

https://issues.apache.org/jira/browse/JCR-2183

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
>

Re: Ceckin/-out, Locking - Description and tests missing in the Spec/TCK

[Alexander Klimetschek <ak...@day.com>]

On Sat, Oct 31, 2009 at 19:15, Daniel Manzke
<da...@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.

> 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