[
https://issues.apache.org/jira/browse/OAK-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343052#comment-14343052
]
Michael Dürig commented on OAK-2384:
------------------------------------
After a lot of poking around I came to the conclusion that the current
behaviour is actually the right one. That is, we should specify JCR Values to
be 'short lived' and that they might not survive a gc cycle. So it is the
clients responsibility to re-fetch them. This is already facilitated by the
work being done on OAK-2407. OTOH with SLING-4307, Sling preemptively adapted
to the new contract already.
IMO the only thing left do do here is to make sure we don't throw a
{{SegmentNotFoundException}} when accession a collected value but wrap it into
a {{RepositoryException}}.
> SegmentNotFoundException when keeping JCR Value references
> ----------------------------------------------------------
>
> Key: OAK-2384
> URL: https://issues.apache.org/jira/browse/OAK-2384
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Priority: Critical
> Labels: gc
> Fix For: 1.1.8, 1.0.13
>
> Attachments: org.apache.sling.jcr.resource-2.4.0.jar
>
>
> With OAK-2192 revision gc started to remove segments older than a certain
> threshold. The underlying assumption was that old sessions would call refresh
> (i.e. auto refresh) anyway once they become active again. However, it turns
> out that refreshing a sessions does not affect JCR values as those are
> directly tied to the underlying record. Accessing those values after its
> segment has been gc'ed results in a {{SegmentNotFoundException}}.
> Keeping reference to JCR values is an important use case for Sling's
> {{JcrPropertyMap}}, which is widely used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
