[
https://issues.apache.org/jira/browse/SLING-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582014#comment-15582014
]
Stefan Egli commented on SLING-6070:
------------------------------------
Agreed, we shouldn't make any dependency on underlying order. So if we can't do
without the maps then let's see if this is really a problem. Perhaps it's not
as extremely large commits aren't much of a reality.
> Reduce temporary storage required in JcrResourceListener, call reportChanges
> earlier
> ------------------------------------------------------------------------------------
>
> Key: SLING-6070
> URL: https://issues.apache.org/jira/browse/SLING-6070
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Resource 2.8.0
> Reporter: Stefan Egli
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.9.0
>
>
> As noticed in OAK-4581
> ([here|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15525601&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15525601])
> one advantage of using OakResourceListener over JcrResourceListener (hence
> the term 'optimize for oak' of the config parameter) is that
> OakResourceListener uses a NodeObserver, which calls added/removed/changed
> after each child traversal has finished. This will in turn be used by the
> OakResourceListener to call ObservationReporter.reportChanges. In the
> JcrResourceListener.onEvent case however this is not possible, as the events
> are delivered for each node/property individually, and they first have to be
> 'mapped' to ResourceChanges. This is currently done by keeping maps of
> added/removed/changed ResourceChanges and only after all events (that are
> passed in 1 onEvent) are processed is reportChanges invoked. This has the
> downside of a potentially very large temporary memory usage (these maps can
> get big).
> A suggested improvement is to follow the same pattern as is done in the
> OakResourceListener/NodeObserver pair: to forward the events (by callling
> reportChanges) as early as possible. Since Oak uses a breadth-first tree
> traversal when compiling the jcr events, this fact can be used to detect the
> earliest possible moment to forward events, which is as soon as a child
> traversal has finished. That way, only parent changes need to be kept, not
> the entire tree of changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
