On Wednesday 26 June 2002 09:45 am, Leo Sutic wrote:
> Berin, you can argue endlessly that a socket isn't a component,
> or what makes a component. Point is this:
>
> + There will always be something that fulfills your every
> requirement for a component but that must still be pooled.
>
> + We do not want to write a separate manager for each one of
> those. No matter how much that fits your view of good
> architecture. *It is not practical.*
>
> Can you convince us that you have a better solution than
> what exists now, or that we for some reason do not want the
> container to handle the pooling, do so.
>
> The arguments we have had regarding that would indicate
> that no such solution exists.
The real question:
* Should a user of a component have to be aware of whether or not a component
is pooled *
Since thats a yes/no question, we have two answers:
NO: We *must* stay with transparent pooling in the container. No way to remove
CM.release()
YES: We can create a generic PoolableComponentManager that looks something
like this:
interface PoolableComponentManager
{
Object get();
void release( Object o );
}
Which would then negate the need for discrete managers for each component
type.
-pete
--
peter royal -> [EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
