On Wed, 7 Mar 2001, Casey Lucas wrote:
>
> Well I can do a pool per thread, but my assumption is that there could possibly
> be a lot of tag handlers sitting around. Should this be a concern? Also,
> I don't know the exact thread pooling model that Tomcat uses, but if
> it creates and destroys worker thread, that will hurt the pool-per-thread
> model.
It doesn't matter what tomcat uses - this should work on other containers
and models as well ( most decent containers are reusing the threads,
if they don't probably the performance is bad anyway, or they have
special needs - like small footprint ).
It's important to just keep in mind that maybe later it should be possible
to "tune" this and use some other mechanisms ( in adition or instead of
the pool ).
You probaly don't have to do anything right now - pool is a good start.
> By doing a web application wide collection of pools, there will be a
> synchronized pop (or similar) per handler retrieval and a synchronized
> push (or similar) per handler return to the pool. The synchronization
> will occur for handlers that are in the same pool across pages. Do you think
> this might be a problem?
One collection per webapplication sounds good. Synchronization is not a
big problem right now ( after you 2x the performance it'll be a bit more
visible ). Keep in mind that a GC is also synchronizing, and object
allocation does a sync() too ( most of the time ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
