jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ruchi goel (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-922) jcr mapping layer (OCM) should expose lock owner
Date Wed, 23 May 2007 09:44:17 GMT

    [ https://issues.apache.org/jira/browse/JCR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498172
] 

ruchi goel commented on JCR-922:
--------------------------------

Answering your question 
<What is the interest to add lock info in the data value object ? >

I am designing the checkin/checkout in the following way:

User A checks out node X.
User A locks node X. 

User B cannot update node X since it is locked by User A. 
User B can read the node X. 

User A  unlocks node X
User A checks in the node X. 

User B checks out node X 
User B locks node X. 

Basically, a mutually exclusive lock for a checked  out node. 

In my pojo , I have the following method  which allows checkin only if the lockowner is the
one who is trying to checkin

 public void checkin(String path)throws CMSException {
         pm = getPersistenceManager();
         try{
            if ((pm.isLocked(path))){
                String lockOwner = getLockOwner(); //get lockowner          
                if (lockOwner.equals(session.getUserID())){
                    String lockToken = doc.getLockToken();
                    pm.checkin(path);
                    pm.unlock(path,lockToken); //this call is already adding lock token in
the session if that lock token is not present.
                }                            
            }
         }catch(Exception e){
             throw new CMSException(e.getMessage(),e.getCause());
         }
    }

May be in the above method , I can try  checkin() without checking for the node state (locked
or unlocked), since now you have the check of checking in by the lockowner , already incorporated
in CheckIfNodeIsLocked . This might just work . 
In  case lockowner is checking in , this succeeds  else throws exception.

For a better  understanding , see the following code for checkout.

 public void checkout(String path)throws CMSException {
        pm = getPersistenceManager();
         try{
            pm.checkout(path);
            if (!(pm.isLocked(path))){
                String lockToken = pm.lock(path,true,false);
                Document doc = this.getDocument(path);
                doc.setToken(lockToken);     //currently using property checkedOutBy for persisting
lockToken, can be changed later 
                doc.save();
            }
         }catch(LockedException le){
           System.out.println("Error: " + le.getLockedNodePath() + " is locked by " + le.getLockOwner());
 
         }catch(Exception e){
             throw new CMSException(e.getMessage(),e.getCause());
         }
    }



> jcr mapping layer (OCM) should expose lock owner
> ------------------------------------------------
>
>                 Key: JCR-922
>                 URL: https://issues.apache.org/jira/browse/JCR-922
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jcr-mapping
>    Affects Versions: 1.3
>            Reporter: ruchi goel
>         Assigned To: Christophe Lombart
>             Fix For: 1.3
>
>
> jcr mapping layer 's  persistencemanager.java  does not expose an API for returning lockowner.
Ideally   , the following method 
> public String lock(final String absPath, final boolean isDeep, final boolean isSessionScoped)

> should return a hashmap/String array containing locktoken as well as lockowner. 
> I tried having lockowner as a field in my java object and mapping it to jcr:lockOwner
, so that I can just use getLockOwner() . But the problem is this property gets introduced
in the node only if  the node is locked. So, when I try to insert a node , before I can even
lock it , the insertion fails since there is no property like jcr:lockOwner   till then .

> So, I feel there is need for the above API. It is ok to have it exposed via separate
call in order to maintain backward compatability

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message