[ https://issues.apache.org/jira/browse/OAK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192824#comment-17192824 ]
Angela Schreiber commented on OAK-9187: --------------------------------------- i locally removed the extra {{SessionDelegate.refresh}} calls on lines 53 and 65 of {{LockOperation}} and successfully ran the oak build calling _mvn clean install_. [~reschke], from the annotations it seems you had worked on the JCR lock code in 2018. do you have any concerns or objections regarding the removal of those 2 lines? > LockOperation always calls SessionDelegate.refresh before executing operations > ------------------------------------------------------------------------------ > > Key: OAK-9187 > URL: https://issues.apache.org/jira/browse/OAK-9187 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr > Reporter: Angela Schreiber > Priority: Major > > [~asanso] reported that calls to {{LockManager.isLocked}} (or > {{Node.isLocked}}) always results in the session being forcefully refreshed. > This is inconsistent with other JCR level read operations which either don't > refresh at all or only refresh in the {{SessionDelegate#prePerform}} if the > {{RefreshStrategy}} in place mandates it. > The same seems to apply for those lock-related methods that include write: > The session is always refreshed upon entering the methods, while other write > operations either delegate refresh to the {{RefreshStrategy}} or only refresh > once changes have been committed to the underlying {{Root}}. -- This message was sent by Atlassian Jira (v8.3.4#803005)