On Monday 15 December 2003 00:13, Daniel Dekany wrote:
> > Let's compare with
> >
> > FileInputStream in = new FileInputStream( filename );
> He should of course. The situation with components is a bit different.
> Since for the code that uses the component (looks it up and invoke its
> methods), the lifestyle (~implementation) specific details (as
> lifestyle) should be transparent (i.e. the same code should work
> whatever lifestyle is used by the used component), you end up with
> choosing between: either user should *always* do explicit releasing, or
> *never* do explicit releasing.
This is exactly my argument. As it stands now, release() is available, some
people ignores using it, Stephen suggests it is not necessary...
> This is where it differs from the case of
> InputStream. An InputStream has to be "released" explicitly, but not
> because its implementation details, but because its semantic, which is
> specific for InputStream-s.
YES, Semantics, the hammer hit the nail...
> However, in a
> component management system, *all* kind of widgets are "component"-s,
> regardless of the high-level semantic of that widget.
So, you have now reached my conclusion a couple of days ago. The Disposable
interface is a contract between the container and component, and there is
currently no way to express such Requirement between the component and the
component user.
> > If you have N x 1000 request coming in over a short period of time, you
> > could be running out of file handles, for no real reason (other than bad
> > code). The "web application developer" don't want this, but "has
> > forgotten" about it, which leads to my "Report inappropriate use.", so he
> > can find out about it before it is in a production system.
>
> You mean that it is detected when a component is collected with the GC,
> which was not released()? If so, I think that such testing will too
> often fail to detect the programmer's mistakes. For example, consider
> that you release the object, but outside finally{...}. Thus, your code
> will produce unreleased objects only when the release(...) call is not
> reached because of an exception. It's hard to point out such errors,
> even with thorough testing.
Well, a half-way is better than nothing, IMHO :o)
> 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,
and yet I get my "warning during development" that something is not right.
> 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, 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.
> How to point out programmer mistakes, when the programmer forgets if the
> role requires manual releasing or not? ServiceManager.lookup(role)
> should be allowed for "normal" Roles only (i.e. for Roles that do not
> require manual releasing). For "manually released" Roles it throws
> exception. For "manually released" Roles, user must use
> ServiceManager.lookupAndHold(role) and ServiceManager.release(Object).
> These two methods will throw exception if you try to use them for normal
> Roles.
This is too much change to Framework to get it through the PMC.
End of it all, I have learned two things;
1. I can actually solve my dilemma nicely, without changes to Merlin nor
Framework.
2. There is a missing piece in the puzzle at the moment, regarding
"Requirements" contract between the Service (not impl) and client code. This
has not yet formalized in my head, and only a gut feeling...
Cheers,
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
