Yeah that is what I was thinking about, this jsr is also known as
JCache. Perhaps it is not as supported as I thought, but basically
everything looks like a Map. My thought is that by using such an
interface or by making the cache system pluggable is that we could
swap out cache providers for different scenarios. One thing we are
interested in looking at is using Coherence (http://www.tangosol.com/coherence-overview.jsp
) which is used by atlassian and others for to allow for scaling. This
combined with a pluggable persistence model would allow for different
cluster implementations. I would also be interested in looking at
terracotta (http://www.terracotta.org/confluence/display/orgsite/Home)
or swarmcache (http://swarmcache.sourceforge.net/). While there could
be a lot of work to create a fully clusterable/grid-ed version of
jackrabbit with pluggable cache and persistence managers we might be
able to do this using existing projects. One cool thing is that a lot
of these distributed caches support read-through and write-through (or
even write-behind) semantics for caching which could create an
extremely scalable solution for accessing content using jcr.
-paddy
On Dec 6, 2007, at 12:18 AM, Thomas Mueller wrote:
Hi,
Do you mean https://jsr-107-interest.dev.java.net/ ? I have never
heard about this JSR, but it sounds interesting. Is it still active? I
saw the last update was on 01/19/2005. It says "Draft Specification:
coming soon!". Maybe it would be better to wait until the
specification is available?
This would enable us to use a more pluggable cache model.
Could you explain the use case? Why do you need a more pluggable
cache model?
Regards,
Thomas
On Dec 5, 2007 8:39 PM, Padraic I. Hannon <[EMAIL PROTECTED]>
wrote:
Not sure if this has been brought up, however, has this group
considered
moving towards using the JSR-107 spec for the internal jackrabbit
caching? This would enable us to use a more pluggable cache model.
Thoughts?
-paddy
