> -----Original Message-----
> From: ext Sean Legassick [mailto:[EMAIL PROTECTED]]
> Sent: 27. February 2001 14:54
> To: Turbine
> Subject: Re: [IDEA] Handling of DynamicURIs.
>
> > Pooling wouldn't provide so much benefits as it seemed at
> the first glance.
> > DynamicURI has two Vectors and ParameterParser one
> Hashtable that are
> > allocated dynamically. The other memory consumers are
> mainly local variables
> > within methods, which can't be pooled. If both classes were
> explicitly
> > restricted to be used within a single thread only (as at least
> > ParameterParser implicitly is when used through the
> RunData), some of the
> > local variables could be changed to class variables, which
> would decrease
> > memory consumption together with pooling.
>
> I don't get this; ParameterParser - the class - can be used by many
> threads at once...
Sorry about being so unclear, I mean that if it's made explicit in the
javadoc of the classes that they are not thread safe and their instances can
be used only within the scope of processing a single request, then class
variables can be used as buffers maintaining the state of the one and only
request linked to the instances. This is also the required precondition to
change synchronized Vectors and Hashtables into non-synchronized ArrayLists
and HashMaps. TurbineRunData is already based on this principle.
-- Ilkka
--
Nokia Networks
http://www.nokia.com/networks
mail: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
