Apply the TransactionFlow
attribute on the
contract, not the service class.
Do not perform transactional work in the service constructor.
Using this book's terminology, configure services for either Client or Client/Service transactions. Avoid None or Service transactions.
Using this book's terminology, configure callbacks for either Service or Service/Callback transactions. Avoid None or Callback transactions.
When using the Client/Service or Service/Callback mode, constrain the binding to
flow transactions using the BindingRequirement
attribute.
On the client, always catch all exceptions thrown by a service configured for None or Service transactions.
Enable reliability and ordered delivery even when using transactions.
In a service operation, never catch an exception and manually abort the transaction:
//Avoid:
[OperationBehavior(TransactionScopeRequired = true)]
public void MyMethod( )
{
try
{
...
}
catch
{
Transaction.Current.Rollback
( );
}
}
If you catch an exception in a transactional operation, always rethrow it or another exception.
Always use the default isolation level of IsolationLevel.Serializable
.
Do not call one-way operations from within a transaction.
Do not call nontransactional services from within a transaction.
Do not access nontransactional resources (such as the filesystem) from within a transaction.
With a sessionful service, avoid equating the session boundary with the transaction boundary by relying on auto-complete on session close.
Strive to use the TransactionalBehavior
attribute
to manage transactions on sessionful services:
[Serializable] [TransactionalBehavior] class MyService : IMyContract { public void MyMethod( ) {...} }
When using a sessionful or transactional singleton, use volatile resource managers to manage state and avoid explicitly state-aware programming or relying on WCF's instance deactivation on completion.
With transactional durable services, always propagate the transaction to the store
by setting SaveStateInOperationTransaction
to
true
.
3.145.101.81