Noel J. Bergman wrote:
Noel, your name is relatively new to me so I will give you some history.Berin,for Avalon ME (Micro Edition)
I think the memory constraints rule [pooled and "factory" components] out.
OK, can you clarify this? At first I thought that you were saying that pooling and factory pattern imply greater memory constraints, with which I disagree. But then I read the rest of your note, where you propose using "http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider";, and since that approach uses a factory to construct the concrete provider, you clearly are not discarding the factory pattern. So I feel that I am missing your real point.
The "Developing with Avalon" whitepaper I wrote identified the concept of "lifestyle" of components.
Lifestyle is a term I coined to refer to how component instances are created and managed. ECM (which
was the only alternative to Phoenix at the time) had three basic types of lifestyle which by name are:
"poolable", "factory", and "thread-safe". Fortress added one more which is "per-thread" or ThreadLocal.
The term "factory" has already been pointed out as not accurate, but it is already in use. Essentially the
difference is this:
* "poolable" components have a soft limited pool of components to satisfy requests for them. When
the maximum size of the pool is exceeded the pool imitates the "factory" lifestyle described next.
* "factory" components create a new instance of a component each time it is requested from the ECM.
* "threadsafe" components have only one instance of components for all requests from the ECM.
* "per-thread" components have one instance of a component per thread.
For an ME container, it is important to keep the number of component instances to a minimum.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
