[
https://issues.apache.org/jira/browse/JCR-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834251#action_12834251
]
Michael Dürig commented on JCR-2498:
------------------------------------
Here's the patch mentioned in [2] above.
Index:
src/test/java/org/apache/jackrabbit/jcr2spi/benchmark/ReadPerformanceTest.java
===================================================================
---
src/test/java/org/apache/jackrabbit/jcr2spi/benchmark/ReadPerformanceTest.java
+++
src/test/java/org/apache/jackrabbit/jcr2spi/benchmark/ReadPerformanceTest.java
@@ -136,7 +136,7 @@
final List<Item> items = new ArrayList<Item>();
for (int k = 0; k < count; k ++) {
- switch (rnd.nextInt(4)) {
+ switch (rnd.nextInt(3)) {
case 0: { // getItem
callables.add(new Callable<Long>() {
public Long call() throws Exception {
> 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
>
> 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.
