You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by David Buchmann <da...@liip.ch> on 2012/01/10 11:34:49 UTC
locking and webdav
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
while implementing locking for the phpcr implementation jackalope that
talks with the jackrabbit davex backend, we tried to understand locking
in jackrabbit. but the following code does what we would expect:
Session s = repo.login(sc,workspace);
Node t = s.getRootNode().addNode("test", "nt:unstructured");
t.addMixin("mix:lockable");
s.save();
LockManager m = s.getWorkspace().getLockManager();
Lock l = m.lock(t.getPath(), false, true, 1, "me");
System.out.println(l.getSecondsRemaining());
it prints 2147483
is this feature not implemented in davex? it seems to me that the server
is neither respecting the timeout of 1 second, nor that this should be
session scoped. it just makes a lock that stays until i restart jackrabbit.
is there a jira issue to track that? i searched for lock and timeout but
did not find anything related to davex.
cheers,david
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8MFEkACgkQqBnXnqWBgIvE3QCgjMbLTvAJo02NmaLaIS408yyx
1+oAoIqcIiMCtG5qhiBqIil5A4E36tiy
=4KXs
-----END PGP SIGNATURE-----
Re: locking and webdav
Posted by David Buchmann <da...@liip.ch>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi julian,
thanks for your answer.
>> Session s = repo.login(sc,workspace);
>> Node t = s.getRootNode().addNode("test", "nt:unstructured");
>> t.addMixin("mix:lockable");
>> s.save();
>> LockManager m = s.getWorkspace().getLockManager();
>> Lock l = m.lock(t.getPath(), false, true, 1, "me");
>
> 1 second sounds short :-)
it was for debugging :-) i now tried with 10 but did not make any
difference.
> I wouldn't be surprised if there a bugs left in this area. If it's
> possible, it would be great to see an HTTP trace to see what's going on
> on the wire.
i created a jira issue to not spam the list with huge dumps:
https://issues.apache.org/jira/browse/JCR-3205
cheers,david
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8OmQQACgkQqBnXnqWBgIvoxACZAU0/gQJZn67ihjiT1w7UbjAd
0Z4AoMFhqSSvXCERtR1og75egcvN1nrF
=FsyY
-----END PGP SIGNATURE-----
Re: locking and webdav
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-01-10 11:34, David Buchmann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi,
>
> while implementing locking for the phpcr implementation jackalope that
> talks with the jackrabbit davex backend, we tried to understand locking
> in jackrabbit. but the following code does what we would expect:
>
> Session s = repo.login(sc,workspace);
> Node t = s.getRootNode().addNode("test", "nt:unstructured");
> t.addMixin("mix:lockable");
> s.save();
> LockManager m = s.getWorkspace().getLockManager();
> Lock l = m.lock(t.getPath(), false, true, 1, "me");
1 second sounds short :-)
> System.out.println(l.getSecondsRemaining());
>
> it prints 2147483
>
> is this feature not implemented in davex? it seems to me that the server
> is neither respecting the timeout of 1 second, nor that this should be
> session scoped. it just makes a lock that stays until i restart jackrabbit.
>
> is there a jira issue to track that? i searched for lock and timeout but
> did not find anything related to davex.
> ...
I wouldn't be surprised if there a bugs left in this area. If it's
possible, it would be great to see an HTTP trace to see what's going on
on the wire.
Best regards, Julian