Sunday, December 14, 2003, 5:34:45 PM, Niclas Hedhman wrote:
[snip]
>> But the real problem with "release always" is that explicitly releasing
>> all components is a big PITA. try{...}finally{release},
>> try{...}finally{release}, try{...}finally{release}...
>
> I am not saying that we scrap Stephen's approach, but leverage on it. By
> requiring release(), yet depend on automatic reclamation, we get both side
> satisfied, no?
> You don't need the try{}finall{ release}, since the times when the exception
> is thrown is so seldom that you can safely rely on the automatic reclamation,
I don't think so... however, I admit I'm bit paranoid. :) Consider, some
long-term malfunction occurs, e.g. a DB server is stopped, so *all*
operation that tries to access that will throw exception. As a result of
that, a component pool dries out (since the components are not
explicitly released, and GC has long delays), and requests that need
that will wait very long for the pool, which will quickly result in
traffic jam.
Also, I don't know if I "can safely rely on the automatic reclamation".
AFAIK there are technical problems with that.
> and yet I get my "warning during development" that something is not right.
But, if the waring is caused be the exception throws mentioned above...
>> Break the rule about lifestyle transparency discussed above: the
>> programmer who uses the object must know if the component returned for a
>> certain Role has to be explicitly released or not. For example, you say
>> that component returned for Role "databaseConnection" must be explicitly
>> released, always. This setting of the Role (i.e. if it requires manual
>> releasing or not) can't be changed later without breaking the user code,
>> and this has to be stated clearly.
>
> Ok, sounds kind of good, now we need a mechanism to signal Service
> requirements to client code. I suggested elsewhere that those services just
> introduce their own interface ReleaseRequirement,
(Here I would like to note that, IMO it would be better if "release
requirement" is bounds to the Role, and not the Service.)
> and in dispose() those implementations make sure that the explicit
> release() is called prior to the dispose(), which indicate wrong
> lifecycle for these types of components. And at the same time
> deprecate release() as it is not needed.
[snip]
Err... sorry I'm don't really see what you mean... more concretely?
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
