[ 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.