cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [RT] Alternatives to Poolable
Date Tue, 10 Feb 2004 18:34:46 GMT
> From: Sylvain Wallez [mailto:sylvain@apache.org] 
>
> Are they intrinsically big, or are they big because of all the stuff 
> every instance must hold that could be delegated to the "component 
> fields" I suggested?

"Component fields".

> I think most components fall in that second category.

Me too. Basically, poolable components are components with a high
cost of initialization. But at the same time, all components in the pool
have the same configuration etc. and thus the same initialization
parameters. This makes all components in the pool clones - when
a component is put back into the pool it must be reset.

Thus, all poolable components can be created anew for each use, if
we could just take a snapshot of the component just after 
initialization.

The big exception to this is when each component isn't equal - 
for example, a DB connection pool has each component corresponding
to a *different* connection.

> Furthermore, pipeline components are stateful because of the 
> asynchronous nature of SAX, but that state doesn't survive past the 
> processing of a pipeline: the state is initialized on startDocument() 
> and trashed on endDocument(). Hence the possibility to change these 
> components into factories.

I'd go for the change-to-factories approach.

Less magic, and it is a well-established pattern.

/LS


Mime
View raw message