3.17.4 Message Processing Events and Sequencing Rules
When processing an incoming ORPC call, the server MUST:
Look up the activity ID of the object that is processing the ORPC call.
Look up the list of objects that share the same activity.
For each object in the list, the server MUST:
Determine the causality identifier of the outstanding ORPC call to the object.
If there is a causality identifier, the server MUST:
Compare the causality identifier of the outstanding ORPC call to that of the incoming ORPC call.
If they are the same, the server MUST allow the incoming ORPC call to the current object to be executed.
If they are different, the server MUST:
Start the activity timer.
Attempt to take the activity lock.
If the timer expires, the server MUST reject the incoming ORPC call as specified in section 3.17.5.
If the activity lock is acquired, the server MUST:
Set the causality identifier of the current object to that of the incoming ORPC call.
Reset the activity timer.
Allow the incoming ORPC call to be executed.
If there is no causality identifier, the server MUST examine the next object.
If there are no outstanding ORPC calls on any object in the list, the server MUST:
Take the activity lock.
Set the causality identifier of the current object to that of the incoming ORPC call.
Allow the incoming ORPC call to be executed.
When the ORPC call completes, the server MUST:
Remove the causality identifier associated with the current object.
Relinquish the activity lock.