jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-224) Lock: Session.addLockToken(String) does make the session to a lock holder
Date Tue, 27 Sep 2005 14:35:48 GMT
    [ 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


Mime
View raw message