jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (Jira)" <j...@apache.org>
Subject [jira] [Commented] (OAK-9187) LockOperation always calls SessionDelegate.refresh before executing operations
Date Fri, 08 Jan 2021 13:51:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17261314#comment-17261314

Marcel Reutegger commented on OAK-9187:

bq. do you know who is maintaining the JCR locking implementation in Oak?

I assume no one is. The initial implementation is from 2013 and did not get much attention.

bq. As stated in the description read-only operations in Oak don't usually cause an automatic
refresh of the Jcr Session and I think Node.isLocked should follow that pattern as well. I
don't know the why this different is the case here.

Most likely the implementation does a refresh to mimic the classic Jackrabbit behaviour. IIRC
the effect of lock operations became visible to other sessions immediately.

Given the current state of the locking implementation in Oak, I'm also in favour of removing
the refresh. The 'benefit' does not seem to justify the cost.

> 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
>         Attachments: OAK-9187.patch
> [~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

View raw message