Transactional Instance Management

As a best practice, use per-call instancing for transactional services. Every instance is disposed after method calls, no matter whether the transactional resources are committed or aborted much later depending on the outcome of the distributed transaction. This ensures that no instance is left with an invalid memory state because of a potential rollback.

This behaviour is even enforced by WFC for per-session instancing. Whenever an instance completes a transaction, either explicitly or declaratively, the instance is disposed of. Note that the distributed transaction may commit or rollback later on. This behavior is ensured by the ReleaseServiceInstanceOnTransactionComplete service behavior, which defaults to true for SessionMode.Required services.

When set to false, ReleaseServiceInstanceOnTransactionComplete will ensure that the per-session instances survive their client's transaction boundaries. This is perilous, since a client rollbacking it's transaction would leave the instance in an invalid state.

Another possible solution is to limit the session to a single client transaction by setting the TransactionAutoCompleteOnSessionClose behavior to true, while avoiding completing the transaction between operations by setting the TransactionAutoComplete behavior to false. By avoiding letting the instance live past the transaction's scope, we are sure not to keep an inconsistent memory state should the transaction abort.