Home > WCF > WCF # 16 – WCF Operation Behavior (Transactional Operations Within a Service) [Part I]

WCF # 16 – WCF Operation Behavior (Transactional Operations Within a Service) [Part I]

Hi Geeks,

In our last two posts we gone through WCF Service Behaviour’s.

Today we will go through the second type of WCF Behaviour called Operation Behaviors.

** Operation behavior’s are scoped at the operation level and are well-positioned for manipulating serialization, transaction flow, and parameter handling for a service operation.

In this article we will see the transaction flow part of Operation Behaviors.

There are two scenarios commonly referred to as transactions.

i) Multistep business processes are long-running processes that typically span minutes, days,
or months. They could involve multiple organizations and human-based workflow.

ii) Short-running transactions are business operations that typically complete in seconds and have few external dependencies. Although they both have well-defined interfaces and a deterministic workflow, they are fundamentally different animals.

Short-running transactions encapsulate discrete business functions.They typically take seconds to complete.

* The business functions can be exposed at a high-level (for example, Open New Account) to aggregate or update information from multiple sources.                                                           It can also be exposed at a lower level (Update Customer Address) to update just one data source.                                                                                                                                       In either case, all data updates within the transaction must succeed or fail as an atomic unit to maintain integrity of the business function.
If one component update fails within the transaction, the service must undo the updates that succeeded prior to the failure so that it leaves the data exactly as it was found before the operation began.

This behavior is commonly known as an ACID transaction. Much has been written on this topic, but in short ACID transactions are

Atomic – All updates within the transaction are successful, or they’re
all rolled back. No partial updates are allowed. For instance, in a bank transfer, if the debit succeeds but the credit fails, the debit is rolled back so money isn’t created or lost.
Consistent – After the operation, all data is valid according to the business rules. For instance, in a bank transfer, the To and From accounts must be valid accounts or the transaction will abort.
Isolated – While the operation is executing, no partial results are visible outside the transactions. For instance, as a bank transfer is being executed, other users will not see the balances part way through the transfer.
Durable – After the transaction is committed, the data must be persisted
in a way that can survive system failures.

**  Transactional Operations Within a Service

Transactional service operations succeed or fail as a unit. They are initiated by one party, which assumes that the result will be consistent, whether the operation succeeds or fails.

To understand transactional operation lets take an example of transferring the amount from bank account .The client opens a connection to the service and calls its Transfer method.Transfer executes a debit, a credit, and then marks the transaction
complete. The client is uninvolved in the transactional semantics.

image

* To implement this behavior in WCF, the service operation must be marked as transactional using the [OperationBehavior(TransactionScopeRequired = true)].  

This directs WCF to create a new transaction and enlist the execution thread on that transaction before dispatching control to the method. If the operation fails before it is complete, all partial updates to transactional resources within that transaction are rolled back.

If  [OperationBehavior(TransactionScopeRequired = false)] is specified, which is the default,the operation executes without a transaction. In that case, the operation will
not support ACID properties. If the operation updates one table and then fails updating a second table, updates in the first table will be persisted and
the ACID property is violated.

Note – By using the [OperationBehavior(TransactionScopeRequired = true)]
behavior, the operation is implicitly considered complete if it doesn’t throw an error. If it throws an error, it is considered incomplete and partial updates to transactional resources will be rolled back.

The operation Transfer,is transactional and is marked as such with the operational behavior [OperationBehavior(TransactionScopeRequired = true)] .

     [OperationBehavior(TransactionScopeRequired = true)]
      private void Transfer(string from, string to, double amount)
        {
          //Buisness Logic
       
}

Thanks , hope this helps.

Advertisements
Categories: WCF
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: