Hello,
E.g. the Turbine project has applied pooled Velocity tools for years, but the benefits are not so clear. Creating a new simple object in Java is much faster than getting one from the pool because of the synchronized tests required by the pooling mechanism to find the correct object, to handle empty pools, etc. If the initialization of the tool requires a lot of time, then pooling could be faster. On the other hand, you typically need to re-initialize the tool for the current context when you got it from the pool, too.
One advantage is to have better controlled memory management with less GC as you can design your pool sizes based on actual requirements of your application. However, the GC mechanism in 1.4 is also quite efficient as it runs in backgound without synchronizing with other threads. Also the shared memory feature in 1.4 can be applied to statically share memory between tool instances requiring large memory blocks.
Anyway, Commons Pool implements a generic pool mechanism which should be applicable also to Velocity tools if needed.
-- Ilkka
Claude Brisson wrote:
On Mon, 2005-01-24 at 02:24 +0900, Shinobu Kawai Yoshida wrote:
Hi Claude,
I take profit of this mail to let us speak a bit about tools (more for devs).
Then let's take it to the dev list. :)
We spoke before about tools pooling (especially Nathan iirc): how can it be implemented? Using a Reusable interface with a reinit(initdata) method?
Made me wonder, how many people actually needs this feature? On what occasions would they use it?
It's more an optimisation than a new feature. So all people having high traffic sites could benefit of it.
For instance, you could have a pool of, let's say, twenty instances of the ParameterParser tool -with a reinit() method- instead of recreating one at each request.
In most cases (whenever it makes sense), it is far faster to only re-initialize an object than to have to instanciate it from scratch.
And a suggestion on the same subject:
Maybe we could have the syntax of the scope element be: application | session | request | <url regexp> in toolbox.xml to refine scopes at a thiner level than the request scope.
Sorry, but I'm not quite getting it. How would one use it? The <url regexp>, I mean.
This is also meant at providing some optimization. Tools with such a scope would be request tools that are instanciated if and only if the url of the request matches the regexp provided in the toolbox.xml. It seems to me that this approach is far better MVC than the $toolLoader.loadTool("thetool") approach.
For instance, a SearchTool can be put in the context only if the url is like /search/*.vm
In fact I am more or less ready to code those suggestions, but I wanted to somehow discuss the specs here so it get more chances to get commited as is.
Claude
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
