commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [scxml] Transitions without targets compete for enablement
Date Mon, 20 Sep 2010 22:08:03 GMT
On Mon, Sep 20, 2010 at 5:25 AM, Hallvard Trætteberg <hal@idi.ntnu.no> wrote:
>  Hi,
>
> I'm trying to implement a state such that whenever some event (in a
> predetermined set) occurs a corresponding actions should be performed, e.g.
> whenever event eA occurs, action aA should be performed, whenever event eB
> occurs, action aB should be performed etc. I've implemented this using one
> targetless transition for each event/action pair, so that the appropriate
> action is performed without leaving the state. Now I've discovered that only
> the first transition (in document order) is enabled, if several events are
> triggered at the same time. I understand that if there are several
> transitions out of a state, only one can be enabled. However, none of my
> transitions have a target so I thought they could all be enabled at the same
> time. What's the reason for not allowing this?
>
<snip/>

You're correct that in this case both (or more than two) transitions
could be selected. The selection process in v0.9 picks the first
transition in document order (from each orthogonal region, if there
are such regions) without inspecting the transition targets, and that
could be changed to pick more if there are no conflicts.

However, the correct solution for Commons SCXML is to port the
SCXMLSemantics impl in use to match more closely the current algorithm
specified in an appendix of the latest SCXML WD which always ensures
that only one event is processed at a time (even internal events are
queued). This change is slated for v1.0, and needs a JIRA ticket
opened against it so it can be tracked -- you can open the ticket if
you want, or I'll open it when I get a chance. Unless a patch becomes
available, I don't expect to be able to update the impl for atleast
another month.

One interim solution may be to design a slightly smarter custom action
for a wildcarded transition that initiates appropriate processing
based on the event(s) being processed.

-Rahul


> Hallvard
>

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


Mime
View raw message