From various ranger talks (and some suggestions from Bill Chessnut) I realised that persistance points were not always what you wanted (especially for performance reasons). NOTE: Call orchestration shapes do not cause persistance points so there is good reason to split large orchestrations into smaller ones (ie. orchestration modularisation/ratioanlisation)

Here is the list of persistence points (does not include call orchestration):

  • The end of a transactional scope is reached.
  • A debugging breakpoint is reached.
  • A message is sent with the exception of message being sent in atomic scope
  • The orchestration starts another orchestration asynchronously (as in Start Orchestration shape)
  • The orchestration instance is suspended.
  • The system shuts down under controlled conditions (Abnormal termination not included)
  • The engine determines that the instance should be dehydrated.
  • The orchestration instance is finished.