On Saturday 13 December 2003 20:31, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> >public interface ReleaseRequirement
> >{
> > /** Releases external resource that may be held by the service.
> > * Failure to call this method may cause fatal errors later in code
> > * execution.
> > */
> > void release():
> >}
> >
> >public interface MyService extends ReleaseRequirement
> >{
> > // whatever
> >}
>
> How is this different from dispose? As far as I can see what you are
> really saying is that you want a contract that forces commissioning,
> action and decommissioning within a particular controlled scope.
It's about explicitly exposing the requirement of release() to the client
code! For a given Service, I typically have two to 20 implementations, and
over time some types will grow continously.
You are not supposed to do a
public interface MyService extends Disposable
{}
Not only is it ugly, but it will easily be misconstrued.
> E.g.
>
> MyService service = (MyService) manager.lookup( "my-service" );
> service.executeTransactions( m_actions );
>
> The component MyComponent implemeting MyService can then aquire the
> actual service that does the work, apply a series of actions, then
> release the service before returning from the call. This way your in
> control of the aquisition/release cycle.
I guess so, but it will be an awful ugly looking piece of code, creating a set
of anonymous classes/objects an passing in an array. Did I say I don;t like
anonymous classes much?
lookup()
do1()
do2()
do3()
release()
is much better IMHO.
> Does your scenario does let you isolate the aquisition/release cycle to
> this level of granularity?
Not sure what you mean.
In any event, by doing the ReleaseRequirement (which I didn't really realize
until we had this GC discussion), I can do what I need, without changing
Framework nor Merlin. And by "harnessing" the "auto reclamation" call via
dispose(), I can detect that it was reclaimed implicitly, but expected it to
be released explicitly, and notify the project implementation developer
during the development, and prevent a disaster later (my kind of apps are
expected to run at least a year without problems, restarts or manual
attention, so intermittent problems after commissioning of the code into a
project is the worst kind, since they are not attended to, nor recreatable).
Back to the bottom-line; What about ServiceManager.release()?? Should it be
deprecated?
IMHO,
1. Deprecated, or
2. Enforced, or "soft enforced" (i.e. reported as a problem).
I don't really care which one, but having a weak contract is not good.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
