[EMAIL PROTECTED] wrote:
> But in tomcat 3.3 we do a different trick - the thread pool is maintaining
> a "local storage" for each thread, and it's passing it to the worker.
>
> The only synchronization in tomcat is in getting a thread from the thread
> pool - besides that we shouldn't need anything else.
>
> Right now we keep the Request/Request pair - so we have a one-to-one
> relation between "main" request and thread ( in other words, the request
> is allways in the same thread ). Whatever attributes/notes you store in
> the request will be equivalent with thread-local data, without any sync.
That's good. But you still have the global vs local issue outlined in my
last post. Purely local, as you outline above, and proper pooling
management becomes tricky (=how to know how many tag instances to use
for the particular handled request).
> > Sorry, I should have been more specific. Of course object reuse can be a
> > good performance optimization. I'm just saying that you gotta balance it
> > with regard to modern JVM's ability to manage memory and "new" objects.
> > Optimize locally in code, and let the JVM do it globally. That's just
> > IMHO though, so feel free to disagree :-)
>
> :-)
>
> I was thinking the reverse - optimize globally, let the VM optimize
> locally, but it depends on definitions...
The problem is that global management is a tricky business. Say you keep
global pools of tag instances. Not only do you have to manage one
particular tag pool properly (not too big, not too small), you also have
to consider how many other pools are active (too many active pools with
too many tags, and you have a memory consumption problem). Then factor
in the temporal issues, i.e. that some tags are used more often than
others sometimes, and you have a situation that I dare you to find an
optimal algorithm to solve the pool management. And when/if you have
that algorithm, I can bet you quite a bunch of dolares that it won't be
more efficient than letting the JVM manage the memory and making sparse
"new"'s per page anyway.
Or (...standard disclaimer...) what am I missing? :-)
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
