[ https://issues.apache.org/jira/browse/OAK-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Angela Schreiber resolved OAK-9970. ----------------------------------- Resolution: Fixed > Internal code calls LockManager.isLocked(String) > ------------------------------------------------ > > Key: OAK-9970 > URL: https://issues.apache.org/jira/browse/OAK-9970 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr > Reporter: Angela Schreiber > Assignee: Angela Schreiber > Priority: Major > Fix For: 1.46.0 > > > similar to OAK-9966 for {{Node.isLocked}} which calls > {{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object > to be resolved again from the absolute path, when it was already there for > the {{Node}} object. > the same applies for > - version operations that check for the node being locked > - import operation that checks for the target node being locked. > NOTE: this pattern applies for all other lock related methods. but since JCR > locking is not properly implemented, i suggest to focus on the > {{Node.isLocked}} and {{LockManager.isLocked}} methods, which are called > frequently in code that is just performing regular writes. > cc: [~joerghoh] -- This message was sent by Atlassian Jira (v8.20.10#820010)