[
https://issues.apache.org/jira/browse/JCR-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834324#action_12834324
]
angela commented on JCR-2498:
-----------------------------
although i didn't look at the poc-patch in detail....based on our f2f
discussion: looks reasonable to me :)
> Implement caching mechanism for ItemInfo batches
> ------------------------------------------------
>
> Key: JCR-2498
> URL: https://issues.apache.org/jira/browse/JCR-2498
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr2spi, jackrabbit-spi
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Attachments: JCR-2498-poc.patch
>
>
> Currently all ItemInfos returned by RepositoryService#getItemInfos are placed
> into the hierarchy right away. For big batch sizes this is prohibitively
> expensive. The overhead is so great (*), that it quickly outweighs the
> overhead of network round trips. Moreover, SPI implementations usually choose
> the batch in a way determined by the backing persistence store and not by the
> requirements of the consuming application on the JCR side. That is, many of
> the items in the batch might never be actually needed.
> I suggest to implement a cache for ItemInfo batches. Conceptually such a
> cache would live inside jcr2spi right above the SPI API. The actual
> implementation would be provided by SPI implementations. This approach allows
> for fine tuning cache/batch sizes to a given persistence store and network
> environment. This would also better separate different concerns: the purpose
> of the existing item cache is to optimize for the requirement of the consumer
> of the JCR API ('the application'). The new ItemInfo cache is to optimize for
> the specific network environment and backing persistence store.
> (*) Numbers follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
