cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject [flow] end of life of the WebContinuation
Date Tue, 29 Jul 2003 12:37:31 GMT
Hi all,

some 2nd thoughts on my earlier proposal:

> 4/ dispose() the wrapped continuation object upon invalidation
> 
> I'ld like the ContinuationsManager to check if the wrapped 
> continuation is implementing Disposable upon invalidation of it's 
> wrapper WebContinuation.
> 
> While at it it might preform the same service on the wrapped 
> 'userObject' (although I have no direct need for this, it seems a 
> logical extension of the reasoning)

(for the full context read the current flow code or the report 
that introduced this: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105913410112209&w=2)

the adapted proposal:

upon creation of the WebContinuation we currently have typically 
(inside your own Interpreter impl of the callFunction)

WebContinuation wk = continuationsMgr.createWebContinuation(
yourImplSpecificContinuationObject, itsParentWebCont, TIMETOLIVE);


where we could add a forth argument to the method that allows 
(optionally: could be null) to register an object to be called in 
the event of invalidation of the wrapping WebContinuation...

so we would get
interface ContinuationDisposer{
   void disposeContinuation(Object o);
}

plus the new ContinuationsManager gets modified to

public WebContinuation createWebContinuation(Object cont, 
WebContinuation parent, int ttl, ContinuationDisposer disposer)


together with the additional check inside the invalidation 
process that is now not biassing it towards considering Avalon 
components:

[inside ContinuationsManagerImpl.java#_invalidate(WebContinuation)]

   if (wk.getDisposer() != null) {
     wk.getDisposer().disposeContinuation(wk.getContinuation);
   }

which requires the WebContinuation to be changed so it could keep 
the reference to this new Disposer, and the most possibly hide 
the above trick inside it's own invalidate() method.


My suggestion would then be that those Interpreter 
implementations that require this 'notification of cleanup' 
mechanism would opt for imlementing the disposer interface 
themselves (keeping in one place the knowledge of both start and 
end of life)

what do others think?

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message