14 Mar
2007
14 Mar
'07
3:14 p.m.
I have a page that is a mashup of two internal web services - one that
serves organization structure, and another that serves IM presence
indicators - to produce a team listing for each of the groups that own
the content of one of our XWiki instances. Because queries to the first
are costly and their content is updated infrequently, a caching
mechanism is indicated.
I see two ways of doing this: one is to manipulate the URL object for
the outgoing request to provide for normal HTTP caching disciplines.
I'd prefer to do it this way, but haven't a clue at the moment of how to
do it, since it's inside org.dom4j.io.SAXReader, to whose read(String)
method I pass a URL.
Another way that I'd like to investigate in parallel is simply to use
XWiki's caching mechanism to cache the parsed org.dom4j.Document objects
that are returned. Establishing a new cache with a Velocity script
seems straightforward (though of course it requires programming rights):
#set($myCache = $xwiki.xWiki.cacheService.newCache())
$mycache.put("name", $myObject)
$myCache.get("name")
... etc...
but it suffers from two problems: first, it's only in the context of
the request, making it useless; second, there's no way to manage the
freshness exception thrown from the get methods. So apparently a plugin
is indicated; ideally, one that: could be used for any purpose; provided
simple means of specifying cache parameters, such as the freshness rules
and the operation required to refresh the cache.
I think that the best way to use it would look something like:
#set($myCache = $xwiki.myCachePlugin)
$myCache.setParameters(...)
$myCache.cached('$velocityCode') ## should pass the Context, or is
that part of the plugin API?
The method would use the unrendered Velocity code as the key to the
cache, look first in the cache and return it, rendering the code and
caching its result first if the value was not fresh.
In describing this, I'm thinking that the DefaultPlugin actually
provides for a lot of this.
Thoughts, anyone?
brain[sic]
15 Mar
15 Mar
11:28 p.m.
New subject: [xwiki-users] Caching of arbitrary objects
Hi Brian,
What you are trying to do sounds quite cool !
You can either store your cache object in your plugin (but not in the
API wrapper which is request specific).
An easier way is to store it in the Servlet context.
You can get the servlet context using
$context.context.getEngineContext()
You then have access to getAttribute and serAttribute
This is a priviledge script
Ludovic
THOMAS, BRIAN M (ATTSI) a écrit :
I have a page that is a mashup of two internal web
services - one that
serves organization structure, and another that serves IM presence
indicators - to produce a team listing for each of the groups that own
the content of one of our XWiki instances. Because queries to the first
are costly and their content is updated infrequently, a caching
mechanism is indicated.
I see two ways of doing this: one is to manipulate the URL object for
the outgoing request to provide for normal HTTP caching disciplines.
I'd prefer to do it this way, but haven't a clue at the moment of how to
do it, since it's inside org.dom4j.io.SAXReader, to whose read(String)
method I pass a URL.
Another way that I'd like to investigate in parallel is simply to use
XWiki's caching mechanism to cache the parsed org.dom4j.Document objects
that are returned. Establishing a new cache with a Velocity script
seems straightforward (though of course it requires programming rights):
#set($myCache = $xwiki.xWiki.cacheService.newCache())
$mycache.put("name", $myObject)
$myCache.get("name")
... etc...
but it suffers from two problems: first, it's only in the context of
the request, making it useless; second, there's no way to manage the
freshness exception thrown from the get methods. So apparently a plugin
is indicated; ideally, one that: could be used for any purpose; provided
simple means of specifying cache parameters, such as the freshness rules
and the operation required to refresh the cache.
I think that the best way to use it would look something like:
#set($myCache = $xwiki.myCachePlugin)
$myCache.setParameters(...)
$myCache.cached('$velocityCode') ## should pass the Context, or is
that part of the plugin API?
The method would use the unrendered Velocity code as the key to the
cache, look first in the cache and return it, rendering the code and
caching its result first if the value was not fresh.
In describing this, I'm thinking that the DefaultPlugin actually
provides for a lot of this.
Thoughts, anyone?
brain[sic]
------------------------------------------------------------------------
--
You receive this message as a subscriber of the xwiki-users(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic
16 Mar
16 Mar
10:10 p.m.
New subject: [xwiki-users] Caching of arbitrary objects
What you are trying to do sounds quite cool !
Huh. Well, thanks; coming from an ex-Netscaper ("Netscapee"?) who has,
at one time at least, been on the leading edge of cool, I take that as
high cred.
By the way, to which did you refer: my self-styled "mashup" or the
generic read-thru cache plugin idea?
I finally wended my way through the maze of run-time indirections to
where I could get a reference to the XWiki cache that was not scoped
only to the request, and it works fine, even from Velocity, as long as I
avoid any chance of that NeedsRefreshException, which I did initially by
always getting the object from the cache, with a never-expiring
freshness parameter, and optionally calling the method to load it
immediately beforehand.
You can either store your cache object in your plugin
(but
not in the API wrapper which is request specific).
An easier way is to store it in the Servlet context.
Yes, I know I can do it in a plugin, which can easily have its own cache
with its own rules and its own namespace (in fact, I note that the
plugin interface has APIs to whack its cache, and also that many of
XWiki's cache keys are pretty short and not terribly unique, so I was
careful to put a fairly long hierarchical-style prefix on all my key
values); but I just wanted to see if I could do it from within Velocity
so that I could do a quick proof-of-concept. And of course I could
dispense with plugins and cache parameters entirely if the URL handling
within org.dom4j.io.SAXReader.read(String) could be configured to cache
responses just like a browser does.
Working inside the plugin will allow me to catch the
XWikiCacheNeedsRefreshException and refresh the cache, then get it again
and return the value. Or, there may be an even easier way to do it,
seeing that the OSCache object has some concept of listener objects.
Another thing I'd like to do is automatically and pre-emptively preload
a cache entry before it expires, to avoid hanging any real-time
requests.
Also, the presence indicator images, though they have only three or four
distinct values, are cached by the URL of the request - for the
individual user - so they have to be requested for every user. What I
plan to do is have XWiki cache the status and send only the three or
four URLs for the image tags to the browser, which will load them at
most once per page. To do either this or the above requires that I have
some kind of mechanism in XWiki that is more or less autonomous, rather
than only in response to a request. But as far as I know, nothing
happens in XWiki - including loading the context - until it gets a
request, and I don't even know whether a servlet can do anything
autonomously, so that will take more investigation.
Thanks again...
brain[sic]
6491
days inactive
6493
days old
2 comments
2 participants
participants (2)
-
Ludovic Dubost -
THOMAS, BRIAN M (ATTSI)