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] SCXML model thread-safe?
Date Wed, 06 Jul 2011 20:12:38 GMT
On Wed, Jul 6, 2011 at 12:48 AM, Dario D <darac1111@gmail.com> wrote:
> Thank you Rahul. In regards to custom actions in such usage case, from what
> we've seen, a new instance of the custom action class is created on each
> execution of the action. This makes it impossible for two threads to access
> the same custom action object simultaneously. Am I correct?
>
<snip/>

There is a new instance in the model for each instance of the custom
action in the document i.e. the following:

  <onentry>
      <custom:foo ... />
      <custom:foo ... />
  </onentry>

will create two instances of the custom action foo class as children
of the onentry. Either of these instances may be accessed by multiple
threads if the same model is shared across many executors.

Custom actions implementations should be stateless beyond things like
fields that store attribute values which are identical across
invocations and not meant to be mutable. Other state should be derived
within the execute() method by introspecting the state or root context
and persisting changes to said context (which is specific to the
executor).

-Rahul


> 2011/7/5 Rahul Akolkar <rahul.akolkar@gmail.com>
>
>>  On Tue, Jul 5, 2011 at 3:37 AM, Dario D <darac1111@gmail.com> wrote:
>> > Is the SCXML model thread-safe? We're considering to parse the SCXML
>> files
>> > on application startup and then store the resulting SCXML models in a
>> cache
>> > where multiple threads will access them. Should we expect any
>> > inconsistencies? Note that executors will not be cached, and a new
>> executor
>> > will be created per request.
>> >
>> <snip/>
>>
>> The above usage pattern is fine. We have a test or two running in the
>> nightlies that does the above (one model, many executors). Ofcourse,
>> I'd recommend authoring tests that closely match your scenario as
>> well.
>>
>> -Rahul
>>
>>
>> > Thank you!
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>

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


Mime
View raw message