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.