Hi Ben,

sounds good, although there are some things to consider when implementing
it (for the general case; for a very narrow case you don't need to
implement them all):

* ACLs: Depending on the user requesting items from the cache a cached item
could be retrieved or not. Also consider the case, that you cache larger
entities although the backing JCR contains ACLs on a more granular level.
* The benefit is probably rather low if you just cache read resources in
memory, you should be able to cache also multiple higher-level objects for
a resource in that cache (e.g. HTML fragments). If you want to avoid
hitting the disk, I would increase the bundleCacheSize (JR 2.x) or increase
the amount of free usable RAM (Oak).

I guess, that you can [1] as basis for it. A bonus would be if you could
inject sling model objects directly from this cache with just a single
annotation ;-)

Jörg

[1] http://sling.apache.org/documentation/bundles/caching-services.html


2014-07-29 8:15 GMT+02:00 Ben Zahler <[email protected]>:

> Hi all,
>
> We are considering to implement a resource-based caching in Sling.
>
> I have found some efforts to do something similar in the past, but they
> all seem to have been either abandoned or do something different from what
> we have in mind.
>
> So it would be great to get some feedback if it this has been tried before
> and was given up or if our idea is just not what the Sling-world is waiting
> for.
>
> This is what our Sling-Cache would do:
>
> -       deliver sling resources from cache based on an exact path
>
> -       deliver sling resources from cache for a subtree of the repository
>
> The following scenarios would benefit from such a cache:
>
> -       navigation components that are expensive to calculate and are
> identical for whole subtrees of a site
>
> -       cacheable components on non-caheable pages
>
> -       CQ use cases with dispatcher caching invalidate the large sections
> or the whole cache. After an invalidation, for a short time all traffic
> hits CQ/Sling. With resource based caching, this could be improved,
> allowing Sling to scale better.
>
> Of course we would create an open-source implementation of our idea,
> caching either in memory or in the repository itself and leave room for
> other implementations with external caches.
>
> So is this an idea you would love to see implemented or is it rather
> something that you deem unnecessarily complex?
>
> Thanks for any feedback!
>
> Cheers,
> Ben Zahler
>
> Inside Solutions AG | Bahnhofplatz 11 | 4410 Liestal | Schweiz
> Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
> http://www.inside-solutions.ch<http://www.inside-solutions.ch/>
>



-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh

Reply via email to