[
https://issues.apache.org/jira/browse/SCXML-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125046#comment-14125046
]
Ate Douma commented on SCXML-207:
---------------------------------
This issue is caused by the same problem as discovered, and fixed, by SCXML-206.
An SCXML state machine is not supposed to be executed concurrently from
multiple threads. This is by design and by the spec.
I'm not sure where you saw this to be 'ok' in the online documentation, but if
this is in the Commons SCXML documentation then it should be removed.
Note the old Commons SCXML (0.9) implementation didn't allow this either but
enforced this through synchronized methods.
So while with the old Commons SCXML you could (try to) invoke the engine from
multiple threads, they were serialized nonetheless.
The new Commons SCXML implementation no longer uses synchronized methods and
leaves it up to the client code not to trigger events concurrently (should use
#addEvent instead).
Regarding the lookup of the 'current' event name from the system context (and
why not use the event name from Transition):
This is according to the specification, see the description of *_event* in
section [5.10 System Variables|http://www.w3.org/TR/scxml/#SystemVariables]:
{quote}
The SCXML Processor MUST bind the _event variable when an event is pulled off
the internal or external event queue to be processed, and MUST keep the
variable bound to that event until another event is processed. [...] In the
case of <transition> elements that do not contain an 'event' attribute and the
<onexit> and <onentry> handlers of any states that are exited or entered by
such transitions, the _event variable will not have a easily predictable value
since the transition is not being driven by an event. In these cases, _event
will be bound to the last event that was matched against a transition.
{quote}
Also note that the event name in the Transition might not (exactly) match the
'current' event name: it might have been matched on prefix only, or maybe even
be the '*' match all event name.
> Race condition in transition notification for SCXMLListeners
> ------------------------------------------------------------
>
> Key: SCXML-207
> URL: https://issues.apache.org/jira/browse/SCXML-207
> Project: Commons SCXML
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Johannes Wienke
> Assignee: Ate Douma
>
> When using a SimpleSCXMLListener we have seen impossible transitions occur in
> the log output of that listener. After digging around the source code I can
> see the issue that results in theses outputs.
> In order to derive the event name passed as the last argument to
> SCXMLListener#onTransition, the following code inside SCXMLSemanticsImpl is
> used:
> {code:java}
> public void notifyOnTransition(final SCXMLExecutionContext exctx, final
> Transition t,
> final TransitionTarget target) {
> EventVariable event =
> (EventVariable)exctx.getScInstance().getSystemContext().getVars().get(SCXMLSystemContext.EVENT_KEY);
> String eventName = event != null ? event.getName() : null;
> exctx.getNotificationRegistry().fireOnTransition(t, t.getParent(),
> target, t, eventName);
> exctx.getNotificationRegistry().fireOnTransition(exctx.getStateMachine(),
> t.getParent(), target, t, eventName);
> }
> {code}
> When triggering events on the engine from multiple threads (which is ok
> according to the online documentation), a different thread might have already
> replaced the contents of the SCXMLSystemContext.EVENT_KEY context item and
> hence a wrong event name might be used from this point on.
> Actually, I don't even understand why the event name is looked up from the
> context here at all, since is already available inside the transition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
