commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hongming Xiao" <>
Subject Re: A newbie question for SCXML and its persistence
Date Fri, 16 Nov 2007 18:14:31 GMT

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. 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.

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

In order to avoid this from happening, I guess beside persisting the
object soon after I invoked SCXMLExecutor.triggerEvent(), I also need to
persist it soon after I receive each onEtry(), onExit() and onTransition
event. Is this right?

Thanks in advance,
On Nov 15, 2007 2:09 PM, Rahul Akolkar <> 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 <> 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]
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message