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.