[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814544#comment-16814544
]
Michael Dürig edited comment on OAK-8209 at 4/10/19 3:23 PM:
-------------------------------------------------------------
{quote}I guess the real question is, can I depend on this?
{quote}
Yes I think so. This should work.
{quote}[...] refresh may update the underlying node states to reflect a remove
of the tree by another session, which would be fine as well if it is really
removed.
{quote}
That's how I remember it as well. The underlying magic is implemented the way
{{MemoryNodeBuilder}} tracks transient changes. However, I'm not sure how
common this usage pattern is and thus whether you might start seeing bugs that
were hidden so far.
Re. revision GC I don't think this is a concern. We guarantee retention for >=
1 generation (24 hrs if GC runs daily). Older sessions will be refreshed
({{o.a.j.o.jcr.repository.RepositoryImpl.RefreshOnGC}}), which will cause a
refresh on the associated root
({{o.a.j.o.jcr.delegate.SessionDelegate#refresh}}). Although this refresh is
somewhat best effort (sessions might miss it because of race conditions), the
recommendation is not to keep sessions open for long without refreshing them.
The {{types}} {{Tree}} in {{WorkspaceImpl}} is not the only place causing
\{{SNFE}} s in the case of a missed refresh after GC.
was (Author: mduerig):
{quote}I guess the real question is, can I depend on this?
{quote}
Yes I think so. This should work.
{quote}[...] refresh may update the underlying node states to reflect a remove
of the tree by another session, which would be fine as well if it is really
removed.
{quote}
That's how I remember it as well. The underlying magic is implemented the way
{{MemoryNodeBuilder}} tracks transient changes. However, I'm not sure how
common this usage pattern is and thus whether you might start seeing bugs that
were hidden so far.
Re. revision GC I don't think this is a concern. We guarantee retention for >=
1 generation (24 hrs if GC runs daily). Older sessions will be refreshed
({{o.a.j.o.jcr.repository.RepositoryImpl.RefreshOnGC}}), which will cause a
refresh on the associated root
({{o.a.j.o.jcr.delegate.SessionDelegate#refresh}}). Although this refresh is
somewhat best effort (sessions might miss it because of race conditions), the
recommendation is not to keep sessions open for long without refreshing them.
The {{types}} {{Tree}} in {{WorkspaceImpl}} is not the only place causing
\{{SNFE}}s in the case of a missed refresh after GC.
> Improve Node.isNodeType(String) performance
> -------------------------------------------
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Minor
> Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
