> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> > >
> > > Same way as you deal with all resources. ie call close(),
> > > release() etc.
> >
> > So can I assume that every component, or every XXXXManager
> > has a close() or release() method?
>
> Leo, before you go crazy down this road, not every
> XXXXManager needs to work with pooled resources.
OK, if it is a property of the component interface that an
implementation can never, ever be pooled, then fine. No release()
or equivalent. But those would be fairly few.
What about the rest of my mail? Specifically, what about the
proposed contract and use case?
> Consider EJBs--which are the epitome of monolithic design in
> a component architecture. There is no explicit release for a
> component, yet the components are pooled. The container is
> in absolute control of the component.
By requiring all instances to be serializable so they can be
swapped in and out as needed. Do you wish to add that constraint
to Avalon components?
> The point is that it can be done, without an explicit release
> mechanism.
Well yes, but can you please:
1) Describe such a mechanism. Not just theorize about the possible
existence of it.
2) Explain how it allows me to use scarce resources (DB connections).
3) Works with component interfaces without a close() or endDocument()
or similar.
4) Explain how it allows me to switch from pooled to threadsafe
components without changing the way I interact with the
component.
5) Describe all constraints it puts on the component implementation.
Berin, so far you have not produced a single mechanism that does what
you claim is possible without serious constraints being put on the
component writer or user - serious enough to make Avalon utterly
unusable.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
