On Wed, Jul 6, 2011 at 12:48 AM, Dario D <[email protected]> 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 <[email protected]>
>
>> On Tue, Jul 5, 2011 at 3:37 AM, Dario D <[email protected]> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
