You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2005/09/27 14:42:48 UTC
[jira] Created: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Lock: Session.addLockToken(String) does make the session to a lock holder
-------------------------------------------------------------------------
Key: JCR-224
URL: http://issues.apache.org/jira/browse/JCR-224
Project: Jackrabbit
Type: Bug
Components: locks
Reporter: angela
JSR170 says:
Lock.getLockToken():
"May return the lock token for this lock. If this Session holds the lock token for this lock, then this method will return that lock token. If this Session does not hold the applicable lock token then this method will return null."
Session.addLockToken(String lt):
"Adds the specified lock token to this session. Holding a lock token allows the Session object of the lock owner to alter nodes that are locked by the lock specified by that particular lock token."
and:
"Note that, as mentioned above, any user with the correct lock token assumes the power to remove a lock and alter nodes under that lock. It does not have to be the lock owner."
If i remember the discussion regarding the locking correctly, it was decided, that the locktoken is turned to any session, that contains the proper token. And: the Lock.getLockToken() is the only way to find out, whether a given session is allowed to modify a locked node (in contrast to the isLocked() method).
I have the impression, that the current implementation does not respect this:
Lock.getLockToken() passes the call to the LockInfo object. The latter performs the following check:
public String getLockToken(Session session) {
if (session.equals(lockHolder)) {
return lockToken.toString();
}
return null;
}
where the lockHolder is set to a particular session in consequence to Session.addLockToken but only if the lockHolder is null... otherwise the call it is ignored (LockManagerImpl line 468).
however, from the above quotes, i would rather expect, that the method should check, if the given Session holds the lockToken associated with this lock.
regards
angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-224?page=all ]
angela closed JCR-224:
----------------------
Resolution: Invalid
Assign To: angela
JSR170 specification issue --> resolving.
> Lock: Session.addLockToken(String) does make the session to a lock holder
> -------------------------------------------------------------------------
>
> Key: JCR-224
> URL: http://issues.apache.org/jira/browse/JCR-224
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
> Assignee: angela
> Fix For: 1.0
>
> JSR170 says:
> Lock.getLockToken():
> "May return the lock token for this lock. If this Session holds the lock token for this lock, then this method will return that lock token. If this Session does not hold the applicable lock token then this method will return null."
> Session.addLockToken(String lt):
> "Adds the specified lock token to this session. Holding a lock token allows the Session object of the lock owner to alter nodes that are locked by the lock specified by that particular lock token."
> and:
> "Note that, as mentioned above, any user with the correct lock token assumes the power to remove a lock and alter nodes under that lock. It does not have to be the lock owner."
> If i remember the discussion regarding the locking correctly, it was decided, that the locktoken is turned to any session, that contains the proper token. And: the Lock.getLockToken() is the only way to find out, whether a given session is allowed to modify a locked node (in contrast to the isLocked() method).
> I have the impression, that the current implementation does not respect this:
> Lock.getLockToken() passes the call to the LockInfo object. The latter performs the following check:
> public String getLockToken(Session session) {
> if (session.equals(lockHolder)) {
> return lockToken.toString();
> }
> return null;
> }
> where the lockHolder is set to a particular session in consequence to Session.addLockToken but only if the lockHolder is null... otherwise the call it is ignored (LockManagerImpl line 468).
> however, from the above quotes, i would rather expect, that the method should check, if the given Session holds the lockToken associated with this lock.
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Kommentiert: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-224?page=comments#action_12330593 ]
Felix Meschberger commented on JCR-224:
---------------------------------------
Sorry, to intervene from the outside :-)
I agree with Angela's understanding of the spec, that there may be more than one holder of a lock. Because each session to which the lock's tocken has been added becomes a lock holder.
On the other hand there is of course only one lock owner. But there is nothing special to a lock owner except for session-scoped locks which become unlocked when the owning session expires or is logged out.
Consequently, it seems obvious, that Lock.getLock() returns the lock token for each session holding the lock and not just for the lock owner.
> Lock: Session.addLockToken(String) does make the session to a lock holder
> -------------------------------------------------------------------------
>
> Key: JCR-224
> URL: http://issues.apache.org/jira/browse/JCR-224
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
>
> JSR170 says:
> Lock.getLockToken():
> "May return the lock token for this lock. If this Session holds the lock token for this lock, then this method will return that lock token. If this Session does not hold the applicable lock token then this method will return null."
> Session.addLockToken(String lt):
> "Adds the specified lock token to this session. Holding a lock token allows the Session object of the lock owner to alter nodes that are locked by the lock specified by that particular lock token."
> and:
> "Note that, as mentioned above, any user with the correct lock token assumes the power to remove a lock and alter nodes under that lock. It does not have to be the lock owner."
> If i remember the discussion regarding the locking correctly, it was decided, that the locktoken is turned to any session, that contains the proper token. And: the Lock.getLockToken() is the only way to find out, whether a given session is allowed to modify a locked node (in contrast to the isLocked() method).
> I have the impression, that the current implementation does not respect this:
> Lock.getLockToken() passes the call to the LockInfo object. The latter performs the following check:
> public String getLockToken(Session session) {
> if (session.equals(lockHolder)) {
> return lockToken.toString();
> }
> return null;
> }
> where the lockHolder is set to a particular session in consequence to Session.addLockToken but only if the lockHolder is null... otherwise the call it is ignored (LockManagerImpl line 468).
> however, from the above quotes, i would rather expect, that the method should check, if the given Session holds the lockToken associated with this lock.
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-224?page=comments#action_12330594 ]
Dominique Pfister commented on JCR-224:
---------------------------------------
The JCR Specification V 1.0, section 8.4.8 (Effect of a Lock) says:
If a lock applies [...]
Note that since at most one session per repository may hold the
same lock token, serial access to the locked item is ensured.
If there can only be one session that holds a lock token, you have two possibilities to transfer a lock from one session A to another session B:
(1) Explicitely remove the lock token from session A, and then add the lock token to session B.
(2) Save away the lock token, logout session A (which implicitely clears the token's holder from
the lock token) and then invoke addLockToken on session B.
Both of these two approaches will successfully transfer a lock token from session A to session B. What does not work is adding a lock token to session B as long as session A is the holder of this lock token.
> Lock: Session.addLockToken(String) does make the session to a lock holder
> -------------------------------------------------------------------------
>
> Key: JCR-224
> URL: http://issues.apache.org/jira/browse/JCR-224
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
>
> JSR170 says:
> Lock.getLockToken():
> "May return the lock token for this lock. If this Session holds the lock token for this lock, then this method will return that lock token. If this Session does not hold the applicable lock token then this method will return null."
> Session.addLockToken(String lt):
> "Adds the specified lock token to this session. Holding a lock token allows the Session object of the lock owner to alter nodes that are locked by the lock specified by that particular lock token."
> and:
> "Note that, as mentioned above, any user with the correct lock token assumes the power to remove a lock and alter nodes under that lock. It does not have to be the lock owner."
> If i remember the discussion regarding the locking correctly, it was decided, that the locktoken is turned to any session, that contains the proper token. And: the Lock.getLockToken() is the only way to find out, whether a given session is allowed to modify a locked node (in contrast to the isLocked() method).
> I have the impression, that the current implementation does not respect this:
> Lock.getLockToken() passes the call to the LockInfo object. The latter performs the following check:
> public String getLockToken(Session session) {
> if (session.equals(lockHolder)) {
> return lockToken.toString();
> }
> return null;
> }
> where the lockHolder is set to a particular session in consequence to Session.addLockToken but only if the lockHolder is null... otherwise the call it is ignored (LockManagerImpl line 468).
> however, from the above quotes, i would rather expect, that the method should check, if the given Session holds the lockToken associated with this lock.
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-224?page=comments#action_12330589 ]
angela commented on JCR-224:
----------------------------
you don't remember that discussion, because it took place before it was decided that you are going to implement the locking... i'm afraid too :)).
and: it's not clear to me from the spec v. 1.0, that it must work the way it works. i couldn't find a section that says, that only one session can be a lockholder at one time. that's way i'm posting that issue. but maybe i was just blind :)).
kind regards
angela
ps: it might also be that for whatever reason this is simply not possibly. but then the spec should say so clearly
from my point of view. to me it seemed obvious, that there would not be a public method addLockToken(String) if not for this exact reason...
> Lock: Session.addLockToken(String) does make the session to a lock holder
> -------------------------------------------------------------------------
>
> Key: JCR-224
> URL: http://issues.apache.org/jira/browse/JCR-224
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
>
> JSR170 says:
> Lock.getLockToken():
> "May return the lock token for this lock. If this Session holds the lock token for this lock, then this method will return that lock token. If this Session does not hold the applicable lock token then this method will return null."
> Session.addLockToken(String lt):
> "Adds the specified lock token to this session. Holding a lock token allows the Session object of the lock owner to alter nodes that are locked by the lock specified by that particular lock token."
> and:
> "Note that, as mentioned above, any user with the correct lock token assumes the power to remove a lock and alter nodes under that lock. It does not have to be the lock owner."
> If i remember the discussion regarding the locking correctly, it was decided, that the locktoken is turned to any session, that contains the proper token. And: the Lock.getLockToken() is the only way to find out, whether a given session is allowed to modify a locked node (in contrast to the isLocked() method).
> I have the impression, that the current implementation does not respect this:
> Lock.getLockToken() passes the call to the LockInfo object. The latter performs the following check:
> public String getLockToken(Session session) {
> if (session.equals(lockHolder)) {
> return lockToken.toString();
> }
> return null;
> }
> where the lockHolder is set to a particular session in consequence to Session.addLockToken but only if the lockHolder is null... otherwise the call it is ignored (LockManagerImpl line 468).
> however, from the above quotes, i would rather expect, that the method should check, if the given Session holds the lockToken associated with this lock.
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-224?page=comments#action_12330587 ]
Dominique Pfister commented on JCR-224:
---------------------------------------
Well, I'm afraid, I don't remember that discussion and obviously it did not make it into the specification.
Fact is: there can only be one session holding a lock (that is: be the lock holder). I don't consider it very safe to silently withdraw a lock token from one session if some other session adds the same lock token which apparently is what you are suggesting.
> Lock: Session.addLockToken(String) does make the session to a lock holder
> -------------------------------------------------------------------------
>
> Key: JCR-224
> URL: http://issues.apache.org/jira/browse/JCR-224
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
>
> JSR170 says:
> Lock.getLockToken():
> "May return the lock token for this lock. If this Session holds the lock token for this lock, then this method will return that lock token. If this Session does not hold the applicable lock token then this method will return null."
> Session.addLockToken(String lt):
> "Adds the specified lock token to this session. Holding a lock token allows the Session object of the lock owner to alter nodes that are locked by the lock specified by that particular lock token."
> and:
> "Note that, as mentioned above, any user with the correct lock token assumes the power to remove a lock and alter nodes under that lock. It does not have to be the lock owner."
> If i remember the discussion regarding the locking correctly, it was decided, that the locktoken is turned to any session, that contains the proper token. And: the Lock.getLockToken() is the only way to find out, whether a given session is allowed to modify a locked node (in contrast to the isLocked() method).
> I have the impression, that the current implementation does not respect this:
> Lock.getLockToken() passes the call to the LockInfo object. The latter performs the following check:
> public String getLockToken(Session session) {
> if (session.equals(lockHolder)) {
> return lockToken.toString();
> }
> return null;
> }
> where the lockHolder is set to a particular session in consequence to Session.addLockToken but only if the lockHolder is null... otherwise the call it is ignored (LockManagerImpl line 468).
> however, from the above quotes, i would rather expect, that the method should check, if the given Session holds the lockToken associated with this lock.
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-224?page=comments#action_12330600 ]
angela commented on JCR-224:
----------------------------
ok, fine with me...
but i would expect, that Session.addLockToken(String) informs about the success either by a return value or by throwing an exception. jcr throws almost everywhere...
> Lock: Session.addLockToken(String) does make the session to a lock holder
> -------------------------------------------------------------------------
>
> Key: JCR-224
> URL: http://issues.apache.org/jira/browse/JCR-224
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
>
> JSR170 says:
> Lock.getLockToken():
> "May return the lock token for this lock. If this Session holds the lock token for this lock, then this method will return that lock token. If this Session does not hold the applicable lock token then this method will return null."
> Session.addLockToken(String lt):
> "Adds the specified lock token to this session. Holding a lock token allows the Session object of the lock owner to alter nodes that are locked by the lock specified by that particular lock token."
> and:
> "Note that, as mentioned above, any user with the correct lock token assumes the power to remove a lock and alter nodes under that lock. It does not have to be the lock owner."
> If i remember the discussion regarding the locking correctly, it was decided, that the locktoken is turned to any session, that contains the proper token. And: the Lock.getLockToken() is the only way to find out, whether a given session is allowed to modify a locked node (in contrast to the isLocked() method).
> I have the impression, that the current implementation does not respect this:
> Lock.getLockToken() passes the call to the LockInfo object. The latter performs the following check:
> public String getLockToken(Session session) {
> if (session.equals(lockHolder)) {
> return lockToken.toString();
> }
> return null;
> }
> where the lockHolder is set to a particular session in consequence to Session.addLockToken but only if the lockHolder is null... otherwise the call it is ignored (LockManagerImpl line 468).
> however, from the above quotes, i would rather expect, that the method should check, if the given Session holds the lockToken associated with this lock.
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-224?page=all ]
Jukka Zitting updated JCR-224:
------------------------------
Fix Version: 1.0
> Lock: Session.addLockToken(String) does make the session to a lock holder
> -------------------------------------------------------------------------
>
> Key: JCR-224
> URL: http://issues.apache.org/jira/browse/JCR-224
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
> Fix For: 1.0
>
> JSR170 says:
> Lock.getLockToken():
> "May return the lock token for this lock. If this Session holds the lock token for this lock, then this method will return that lock token. If this Session does not hold the applicable lock token then this method will return null."
> Session.addLockToken(String lt):
> "Adds the specified lock token to this session. Holding a lock token allows the Session object of the lock owner to alter nodes that are locked by the lock specified by that particular lock token."
> and:
> "Note that, as mentioned above, any user with the correct lock token assumes the power to remove a lock and alter nodes under that lock. It does not have to be the lock owner."
> If i remember the discussion regarding the locking correctly, it was decided, that the locktoken is turned to any session, that contains the proper token. And: the Lock.getLockToken() is the only way to find out, whether a given session is allowed to modify a locked node (in contrast to the isLocked() method).
> I have the impression, that the current implementation does not respect this:
> Lock.getLockToken() passes the call to the LockInfo object. The latter performs the following check:
> public String getLockToken(Session session) {
> if (session.equals(lockHolder)) {
> return lockToken.toString();
> }
> return null;
> }
> where the lockHolder is set to a particular session in consequence to Session.addLockToken but only if the lockHolder is null... otherwise the call it is ignored (LockManagerImpl line 468).
> however, from the above quotes, i would rather expect, that the method should check, if the given Session holds the lockToken associated with this lock.
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira