Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of rahul.akolkar@gmail.com
 designates 209.85.132.242 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=W8Af/MNIRk4LIjzeiy/hzrQxPudSFcvmkEO28HZOBCgSNe3Lcd6sqyNKy3PvJshyHyVmg3SrLosK+MeWi5T33SklTQM6eIakZWAvDw2UY2zc32zp0Y7ecd6sOqfsHUs90Ts8MufQLZhgriMZiasIgz1w70VTANS2eHmew+6+uHg=
Message-ID: <ce1f2ea80703211731t372957dehe9dbdff51e10a43d@mail.gmail.com>
Date: Wed, 21 Mar 2007 20:31:56 -0400
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [SCXML] Executor is thread safe?
In-Reply-To: <94360.86252.qm@web50901.mail.re2.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <541312.16779.qm@web50908.mail.re2.yahoo.com>
	 <94360.86252.qm@web50901.mail.re2.yahoo.com>

On 3/20/07, Nestor Urquiza <nestoru@yahoo.com> 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 <nestoru@yahoo.com> 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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org