You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Upayavira <uv...@upaya.co.uk> on 2003/07/01 07:04:08 UTC
Re: More on FOM
On 30 Jun 2003 at 22:29, Sylvain Wallez wrote:
...
> >> I suggested that components being heavyweight resource, allowing
> >> them to cross continuation boundaries should be prohibited.
> >> Automatic release doesn't seem a good solution to me, as it would
> >> mean that script variables would hold released components, thus
> >> leading to unpredictable behaviour (think about stateful pooled
> >> components). So my opinion is to raise an error if there are some
> >> unreleased components when a continuation is created. This will
> >> allow users to quickly learn the safe practices related to
> >> component management in flow scripts.
I tend to agree.
...
> Once again, I agree that explicit release is very unnatural. But
> automagic release is good only if we can have some automagic restore.
> For this we can have getComponent() actually return a proxy to the
> real component, and have the proxy do a release/lookup when a
> continuation is suspended/reactivated. But as elegant this may seem,
> this won't work : stateful components have... a state, and a
> release/lookup cycle destroys this state.
>
> So I don't see any other solution...
How about defining a FlowSafe interface (contains no state and can be
released/looked up transparently), and maybe a FlowSerializable interface (has a way
that the state can be stored into the continuation and then restored, all transparently?
So you would have to consciously code your components to use either of these
interfaces, otherwise you'll have to manually release them before creating a
continuation.
Upayavira
Re: More on FOM
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Upayavira wrote:
>On 30 Jun 2003 at 22:29, Sylvain Wallez wrote:
>
>
>
<snip/>
>>Once again, I agree that explicit release is very unnatural. But
>>automagic release is good only if we can have some automagic restore.
>>For this we can have getComponent() actually return a proxy to the
>>real component, and have the proxy do a release/lookup when a
>>continuation is suspended/reactivated. But as elegant this may seem,
>>this won't work : stateful components have... a state, and a
>>release/lookup cycle destroys this state.
>>
>>So I don't see any other solution...
>>
>>
>
>How about defining a FlowSafe interface (contains no state and can be released/looked up transparently),
>
We already have this with the ThreadSafe marker interface. So yes, we
could have transparent release/lookup for ThreadSafe components.
>and maybe a FlowSerializable interface (has a way that the state can be stored into the continuation and then restored, all transparently?
>
Good point. But actually, this is not related exclusively to flow, but
to the ability to externalize the component state. So this could be :
interface StateExternalizable {
Object /* or Serializable? */ getState();
void setState(Object state);
}
>So you would have to consciously code your components to use either of these interfaces, otherwise you'll have to manually release them before creating a continuation.
>
Yep. An you would still get an error if there are some unreleased
components that are neither ThreadSafe nor StateExternalizable.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: More on FOM
Posted by Christopher Oliver <re...@verizon.net>.
Upayavira wrote:
>On 30 Jun 2003 at 22:29, Sylvain Wallez wrote:
>
>...
>
>
>
>>>>I suggested that components being heavyweight resource, allowing
>>>>them to cross continuation boundaries should be prohibited.
>>>>Automatic release doesn't seem a good solution to me, as it would
>>>>mean that script variables would hold released components, thus
>>>>leading to unpredictable behaviour (think about stateful pooled
>>>>components). So my opinion is to raise an error if there are some
>>>>unreleased components when a continuation is created. This will
>>>>allow users to quickly learn the safe practices related to
>>>>component management in flow scripts.
>>>>
>>>>
>
>I tend to agree.
>
>...
>
>
>
>>Once again, I agree that explicit release is very unnatural. But
>>automagic release is good only if we can have some automagic restore.
>>For this we can have getComponent() actually return a proxy to the
>>real component, and have the proxy do a release/lookup when a
>>continuation is suspended/reactivated. But as elegant this may seem,
>>this won't work : stateful components have... a state, and a
>>release/lookup cycle destroys this state.
>>
>>So I don't see any other solution...
>>
>>
>
>How about defining a FlowSafe interface (contains no state and can be
>released/looked up transparently), and maybe a FlowSerializable interface (has a way
>that the state can be stored into the continuation and then restored, all transparently?
>
>
>
Continuations do not serialize state. Continuations restore the program
counter and cause you to retain references to function invocations and
local variables, however they do not "roll back" the values of those
variables.