[
https://issues.apache.org/jira/browse/JCR-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved JCR-2498.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.1.0
Applied a cleaned up/improved version of the patch in revision 915810
> 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
> Fix For: 2.1.0
>
> 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.
