atomic operations

[tom.baeyens]

[1/08/2007 17:59:12] Miguel Valdes Faura says: I was looking to the performAtomicOperation and I guess I got it.
[1/08/2007 17:59:41] Miguel Valdes Faura says: For instance, if the operation is a signal to a Node that behavies as a WaitState...
[1/08/2007 18:00:35] Miguel Valdes Faura says: the previous method is call from the signal and so performs the "perfom" operation into the while
[1/08/2007 18:01:21] Miguel Valdes Faura says: This "perform" call will end up into a new call to the performAtomicOperation method to take the default transition of this node...
[1/08/2007 18:01:50] Miguel Valdes Faura says: and so this operation will be saved as a nextOperation
[1/08/2007 18:02:21] Miguel Valdes Faura says: the while will execute this nextOperation afterward...
[1/08/2007 18:04:48] Miguel Valdes Faura says: What I didn't get is the following:
[1/08/2007 18:06:27] Miguel Valdes Faura says: As each one of those AtomicOperations can be associated with a transaction we could commit the first operation (signal) and if a error occurs the takeTransition operation will not be executed (second atomicOperation)
[1/08/2007 18:06:49] Miguel Valdes Faura says: ?
[1/08/2007 18:07:42] Miguel Valdes Faura says: I was expected to perform both operations (signal + take the next transition) in the same atomicOperation (same transaction)

[tom.baeyens]

as long as atomic operations are executed consecutively, they run in a single transaction.

currently there is no way yet to interrupt inbetween two atomic operations and introduce a async continuation. For that to happen we'll introduce configuration parameters like async='true' on the transition and nodes. Those will have to be checked when atomic operations are created right before the performAtomicOperation is called. probably we will have to introduce something extra like performActomicOperationAsync or so. Then depending on the configurations in the process element, either performActomicOperation or performActomicOperationAsync is called.

[mvaldes]

as long as atomic operations are executed consecutively, they run in a single transaction.

Ok but in this case why not just call the perform() method from within either signal and processNodeState methods rather than use the performAtomicOperations method ?

regards,
Miguel

[tom.baeyens]

because then you would get nested execution again resulting in a big call stack.

calling the performAtomicOperation makes sure that all the atomic operations are executed after each other in a while loop.

[mvaldes]

I'm probably missing something...

In both cases (if there is no asynchronous continuation between) we could get an transaction time out when associating consequently atomicOperations to one transaction.

So, why delayed execution is useful ?

regards,
Miguel Valdes

[mvaldes]

Got it, recursive calls to the performAtomicActivity method could end up in a outOfMemory error (for instance when having multiple automatic activities in sequence). Delayed execution is transforming recursive calls into a while loop.

regards
Miguel Valdes