jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Ceckin/-out, Locking - Description and tests missing in the Spec/TCK
Date Mon, 02 Nov 2009 12:14:11 GMT
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.

> 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

Mime
View raw message