On 3/20/07, Nestor Urquiza <[EMAIL PROTECTED]> wrote:
I have reviewed the code and from what I am running to
what is on SVN there is no difference. There are
basically three methods that are synchronized in the
SCXMLExecutor class so I assume my problem has to deal
with some other issues.
In any case just to understand if I might be doing
something wrong I have several different SCXML files
parsed within the same same JVM. Every time a request
comes I identify the correct SCXML to be followed and
so I create an Executor if it is the first call and if
not I use executor I created when the first call was
processed.
So calls can share the same SCXML (when different
requests share the same usecase) or the same Executor
(when a preceding call for the same session was
already executed and so the next call owns a session
Id equivalent to the current Executor).
<snip/>
Sounds about right, assuming call == (http) request etc.
There are a couple of assumptions made by the executor:
* User isn't programmatically rewiring bits and pieces of the state
machine (SCXML), which I don't think you are.
* Its operations are broken down into one-time and repeating, usage
generally looks something like (as you mention above):
if (executor is not present) {
instantiate it
set root context, evaluator, state machine etc.
// the class doesn't synchronize these init time operations
}
use executor -- trigger events, reset etc. // these are synchronized
TBD whether this distinction is intuitive. But it does seem (from the
comment below) that you're not treating setRootContext() as a one-time
operation. Can you try synchronizing on the executor instance before
you update / change the root context in subsequent requests? Do these
contexts reference shared variables / data? -- generally shouldn't and
if they do the data should either be immutable or synchronized
appropriately.
-Rahul
Thanks,
-Nestor
--- Nestor Urquiza <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> I took a look at version 6.0 and I see in release
> notes is written:
>
> "The SCXMLExecutor instances now provide some
> element
> of thread-safety.
> Firing events on a state machine executor
> instance
> or reseting it
> are synchronized operations. The underlying state
> machine needs to
> model any race conditions correctly."
>
> In my current code I am not synchronizing and
> because
> of that I think sometimes some variables that are
> supposed to be part of one context for a specific
> executor get wrong values from other
> executor/contexts.
>
> Could anyone explain a little bit better (maybe with
> a
> snippet of code) both situations for version 5 and 6
> showing in the first case how the synchronization
> must
> be done externally and for the second one how thead
> safe Executor is guarranteed?
>
> It is kind of dificult to me to provide a JUnit test
> case for such situations but I am seeing mixed
> context
> variables within my application during high traffic
> hours.
>
> Thanks ,
>
> -Nestor
>
> exec.setRootContext(rootCtx);
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
