[ http://issues.apache.org/jira/browse/JCR-533?page=comments#action_12427475 ] Stefan Guggisberg commented on JCR-533: ---------------------------------------
> I've reading the specification and can't find any reference to transient > session in Node.lock(). Do you mean that Node.lock() don't modify transient > session because it performs a Node.save() internally (there is no need to > call save)? whether an implementation internally calls save() is an implementation detail. "there's no need to call save" means that there are no transient modifications which need to be saved by the client. > My english is a little bad an sometimes perhaps I don't use the correct words > and can't express my ideas in the rigth way. no problem, most committers and a lot of people on the list are non-native english speaking ;-) > failing Node.lock() might leave inconsistent transient state > ------------------------------------------------------------ > > Key: JCR-533 > URL: http://issues.apache.org/jira/browse/JCR-533 > Project: Jackrabbit > Issue Type: Bug > Components: locks > Affects Versions: 1.0.1 > Environment: Ubuntu Dapper > Reporter: Paco Avila > Assigned To: Stefan Guggisberg > Attachments: DummyLockAccessDenied.java, > MyAccessManagerLockAccessDenied.java > > > When I try to node.lock(true, false) a node and the lock fails due to lak of > user privilegies, the lock stay in the user transient session. If a perform a > node.refresh(false) the node still is locked in the transient session. -- 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
