commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: A newbie question for SCXML and its persistence
Date Fri, 16 Nov 2007 22:35:43 GMT
Please move this to the user list if you reply (not a dev list topic).

On 11/16/07, Hongming Xiao <xiaohm@gmail.com> wrote:
> Rahul,
>
> Thanks for your clarification. It helps me a lot. I have one more question
> related to this topic.
>
> I am wondering what is the right time to persist this SCXMLExecutor
> object.
<snip/>

Whenever it needs to be persisted :-) i.e. there is no need to treat
it any more (or less) specially than other Serializable objects.


> I am asking since when I went through SCXML spec, I  noticed that
> the event triggerred using <event> action will be queued and handled later.
>  I guess SCXMLExecutor.triggerEvent() has similiar behavior.
>
<snap/>

SCXMLExecutor#triggerEvent() and <event> have different purposes (and
behavior). You can conceptually think in terms of two queues:

 * One lines up external events, lets call this EQ. EQ is not in the
Commons SCXML codebase, in other words, how external events get fed to
the state machine instance depends on the application. If there are
event priorities, access controls, buffering, all that has to
implemented by the user of Commons SCXML.

 * The other maintains internal / derived events that get generated as
the state machine progresses (this includes <event>, for example),
lets call this IQ. Most events in IQ get processed immediately, unless
they are waiting for a timeout. IQ will be persisted (indeed, it'd be
bad to wake up and lose your IQ ;-). There is an interesting question
as relates to deadline or duration driven timeouts in relation to
persistence. It hasn't been addressed (in that nothing special is done
by the impl here).


> Let's say I pesist the object when the event is still in the
> queue.  After then the event is processed and then system crashed. When I
> reload the object,  since the event is in the queue, I guess the event will
> be processed again. If so, notifications such as onEntry, onExit and
> onTransition could  be triggered twice if I have registered a listener for
> them.
>
<snip/>

Seems unlikely, when an event is processed, it also gets removed from
the queue. Moreover, I'm not sure what kind of application you are
talking about -- for example, if its a web application, hopefully the
session fails over and you don't have to do anything beyond that.


> In order to avoid this from happening, I guess beside persisting the
> object soon after I invoked SCXMLExecutor.triggerEvent(),
<snap/>

Again, if thats what you want. In most cases, the amount of time spent
processing events is only a (really) small fraction of the lifetime of
a state machine instance. The rest is "idle time".


> I also need to
> persist it soon after I receive each onEtry(), onExit() and onTransition
> event. Is this right?
>
<snap/>

No, seems like gratuitous overkill IMO.

-Rahul


> Thanks in advance,
> Hongming
> On Nov 15, 2007 2:09 PM, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>
> > Please do not reply in an existing thread and ask an unrelated
> > question, start a new thread instead. Response below ...
> >
> > On 11/15/07, Hongming Xiao <xiaohm@gmail.com> wrote:
> > > Since SCXMLExecutor implemented Serializable interface, I guess the
> > simplest
> > > way is to store serialized object somewhere for recovery purpose.  Does
> > it
> > > work? And/or, any other suggestion?
> > > Thanks in advance.
> > <snip/>
> >
> > Yes, it works. In fact, many of our JUnit test cases that run nightly
> > round trip (serialize and then deserialize) SCXMLExecutor instances.
> >
> > You are correct this is the simplest persistence mechanism at the
> > moment. There was some discussion towards easily allowing alternative
> > persistence mechanisms, see SCXML-20 [1], for example. We need to
> > revisit this later (at v1.0 time).
> >
> > -Rahul
> >
> > [1] http://issues.apache.org/jira/browse/SCXML-20
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message