> > From: "Leo Sutic" <[EMAIL PROTECTED]> > > > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > > > Leo & Leo, > > <snip/> > My views on release(): I hate it. > > Unfortunately, it is the best solution I've been able to find > so far. Rest assured that I'll campaign to have it removed / > deprecated / ignored as soon as it is possible. > <snip/>
> The Java GC is designed to manage memory. While memory is a resource, > all resources aren't equal: As we have seen with file handles, some > are scarce. Some have heavy initialization costs, like db connections. > > Thus, when we try to use the Java GC, which is designed for memory > management, to manage some other resource, we inevitably end up with > a suboptimal mapping. Very astute characterization of the problem. You hit the nail on the head. > Management of components if different from management of memory. <snip/> > start disposing components *now*". Even if there were such an > indicator, the GC doesn't trigger on it - remember, GC cares > about memory management and nothing else. > > So why is release() acceptable and manual dealloc bad? Because the > latter is solved by GC, while the former is a different type of > resource management. Components *have* memory, but *aren't* memory. > So you can't treat them as if they were. Leo, you made this long trail meaningful to follow! Thanks. Now what do you say to just doing away with pooling by the ServiceManager all together and along with it this release() method. Why doesn't the ServiceManager just do one thing and one thing only but very well? Let's keep it really simple and remove the release() method on the interface. The ServiceManager should just be a way to gain access to a service. No presumptions should be made about it and resource pooling. If you need access to resources that are pooled services perhaps we should be thinking about another lifecycle method that extends the Servicable interface using a PoolingServiceManager that does have this release() method available to return pooled resources. These thoughts and suggestions are probably not very clear but perhaps we can find better solutions along a similar track. IMO I think getting a handle on dependent regular service should require the component developer to use the Serviceable lifecycle. The semantics and usage change completely when we talk about pooled services and using another lifecycle to deal with these pooled services is clear and justified. My $0.02, Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
