NET Transactions Training

Copyright © Intertech Training 2005 • www.intertechtraining.com • 800-966-9884 • Slide 5

Session OverviewSession Overview

Review transactions in .NET 1.1– Review some transaction terminology– See the current issues with SqlTransaction and Enterprise Services

Study the new features in .NET 2.0– Understand the role of the Lightweight Transaction Manager (LTM)– See how transaction promotion works– Learn how to manually work with transactions– Learn how to simplify transaction programming with

TransactionScope


The Importance of TransactionsThe Importance of Transactions

Transactions are the cornerstone of any reliable app – Ensure ACID characteristics when updating critical information– Abstract complex compensation logic using simple APIs: e.g.

Commit/Rollback, SetComplete/SetAbort

Transactions are used in a variety of contexts:– Updating a single data source– Updating several data sources (distributed Tx)– Grouping multiple messages that must all be processed in the

correct order (MSMQ)

Service-orientation brings additional Tx needs.– "Services are autonomous" assumes reliability and correctness


Transaction ParticipantsTransaction Participants

ResourceManager

ResourceResourceManagerManager

TransactionManager

TransactionTransactionManagerManager

ApplicationApplicationApplication

SQL Server 2005OracleMSMQTransacted Hashtable

Distributed Tx Coordinator (DTC)Lightweight Transaction Manager (LTM)Etc.


Why Not Why Not TxTx Everywhere?Everywhere?

Transactions are expensive– Tx management causes overhead– Require locks on resources and thus inhibits scalability– Distributed transactions require expensive two-phase commit

mechanisms

Transaction code can be messy– Try/Catch/Finally required to handle exceptions and rollback– Transaction logic is mixed with domain logic

Enterprise Services can clean up the code, but …– Course grained: objects are transactional, not methods– Performance: uses DTC even against a single database– Must derive from ServicedComponent– Retains some COM-like hassles: registration, deployment, etc.


Other Transaction Issues Other Transaction Issues

Different technologies have different Tx APIs:– TSQL – ADO.NET Transactions (e.g. SqlTransaction)– MSMQ: MessageQueueTransaction– Multi-resource updates require Enterprise Services: ContextUtil,

AutoComplete, etc.

Some updateable resources have no Tx support:– File system updates– In memory (volatile) collection objects: ArrayList, Hashtable, etc.


TxTx Scenario 1: Single DB Update Scenario 1: Single DB Update

static void SingleDBUpdate() { using (SqlConnection cnn = new SqlConnection(ConnString)) { cnn.Open(); SqlTransaction tx = cnn.BeginTransaction(); // Must associate tx with each SQL command. SqlCommand update1 = new SqlCommand("DELETE ...", cnn, tx); SqlCommand update2 = new SqlCommand("INSERT ...", cnn, tx); try { update1.ExecuteNonQuery(); update2.ExecuteNonQuery(); tx.Commit(); } catch { tx.Rollback(); } } }


TxTx Scenario 2: Multi DB Update Scenario 2: Multi DB Update

[Transaction(TransactionOption.Required)] public class Mover : ServicedComponent { [AutoComplete] public void Move() { using(SqlConnection cnnDB1 = new SqlConnection(Database1), cnnDB2 = new SqlConnection(Database2)) { SqlCommand cmdDeleteDB1 = new SqlCommand("DELETE ...", cnnDB1); SqlCommand cmdInsertDB2 = new SqlCommand("INSERT ...", cnnDB2); // ADO.NET connections automatically enlist into // the DTC transaction cnnDB1.Open(); cnnDB2.Open(); cmdDeleteDB1.ExecuteNonQuery(); cmdInsertDB2.ExecuteNonQuery(); } } }

Relatively clean code but …• Must derive from ServicedComponent• Must be in strong named assembly• Must register in COM+• Very different from single DB scenario

Relatively clean code but …• Must derive from ServicedComponent• Must be in strong named assembly• Must register in COM+• Very different from single DB scenario


TxTx Scenario 3: DB + Volatile Update Scenario 3: DB + Volatile Update

[Transaction(TransactionOption.Required)] public class Mover : ServicedComponent { [AutoComplete] public void Move(object key) { object val = hashTable[key]; hashTable.Remove(key); using(SqlConnection cnnDB2 = new SqlConnection(Database2)) { // Insert value from hash table into DB SqlCommand cmdInsertDB2 = new SqlCommand("INSERT ...", cnnDB2); cnnDB2.Open(); cmdInsertDB2.ExecuteNonQuery(); } } }

What happens if the DB update fails?

The hashtable value is lost!

What happens if the DB update fails?

The hashtable value is lost!


Transactions in .NET 2.0Transactions in .NET 2.0

.NET 2.0 Transaction goals:– Provide a simple, common programming model for all Tx scenarios– Provide fast Tx management of volatile resources– Reduce initial Tx overhead by defaulting to a minimal manager– Automatically promote to a distributed Tx manager (e.g. DTC)

when needed– Use an efficient single phase enlistment for single resources– Simplify creation of custom resource managers (e.g. roll your own

transacted Hashtable).

Make transactional programming ubiquitous!


.NET 2.0 Transaction Overview .NET 2.0 Transaction Overview

System.TransactionsSystem.Transactions

Manual TxCommittableTransaction


Implicit TxTransactionScope


Declarative TransactionsDeclarative Transactions

Lightweight Transaction ManagerLightweight Transaction Manager

.NET 2.0

Indigo

Distributed TxCoordinator


Participates when neededTransactional FS

(Longhorn?)Transactional FS

(Longhorn?)


Lightweight Transaction Manager Lightweight Transaction Manager

The Lightweight Transaction Manager (LTM) is – The common starting point for all Txs– A full-fledged Tx manager for volatile resources– Extremely fast: minimal overhead when using volatile resource in

same app domain

LTM provides a "pay as you go" mechanism– Promotes the Tx to other managers as needed– Uses Promotable Single Phase Enlistment (PSPE) when interacting

with a single remote resource manager – Uses DTC for a single remote RM that does not support PSPE– Uses DTC for multiple remote RMs


LTM: Dynamic Transaction Promotions LTM: Dynamic Transaction Promotions

The LTM promotes Txs automatically

When an application starts a transaction:– LTM creates and owns the Tx– User touches an RM, RM auto enlists– If RM is volatile, LTM continues to own Tx– If RM is durable PSPE (like SQL Server 2005), LTM transfers

ownership to RM– If 2nd RM enlists, or if RM is remote, LTM transfers ownership to

DTC



LTMLTMLTM

Start Transaction

Start Transaction



LTMLTMLTM

TxHashTable.Add()

Start Transaction

TxHashTable.Add(…)Enlist Volatile



LTMLTMLTM

SqlExecute(cmd1)

Start Transaction

TxHashTable.Add(…)

SqlExecute(cmd1)

Enlist durable and PSPE

SQL Server2005

SQL Server2005

SQL Server2005

SQL Server2005



LTMLTMLTM

SqlExecute(cmd2)

Start Transaction

TxHashTable.Add(…)

SqlExecute(cmd1)

SqlExecute(cmd2)

Enlist durable

SQL Server2005

SQL Server2005

SQL Server2005

DTCDTCDTC


Performance: LTM vs. Enterprise ServicesPerformance: LTM vs. Enterprise Services

Test Computer:•256 MB RAM•1 x 0.757 GHz

480.60 544.27 622.17 809.29 915.18

159509.67153201.00

148116.17139601.33

125694.17

20000

160000

140000

120000

100000

80000

60000

40000

01 2 4 8 16

Tran

sact

ions

per

sec

ond

Enterprise Services

System.Transactions

• Radically reduced intra-app domain transaction overhead

• ~3 microseconds to start/commit a null transaction on this processor










.NET 2.0

Indigo



Participates when neededTransactional FS

(Longhorn?)Transactional FS

(Longhorn?)


.NET 2.0 Manual Transactions .NET 2.0 Manual Transactions

The Transaction Class

[Serializable] public class Transaction : ITransaction, IDisposable, ISerializable { // Properties public static Transaction Current { get; set; } public IsolationLevel IsolationLevel { get; } public TransactionInformation TransactionInformation { get; } // Methods public Transaction Clone(); public void Rollback(Exception e); }

Here's Rollback, but where is Commit?



The CommittableTransaction Class

[Serializable] public sealed class CommittableTransaction : Transaction { public void Commit(); public IAsyncResult BeginCommit( AsyncCallback asyncCallback, object asyncState); public void EndCommit(IAsyncResult asyncResult); public CommittableTransaction(); public CommittableTransaction(TimeSpan timeout); public CommittableTransaction(TransactionOptions options); }



TransactionOptions

[Serializable] public sealed class CommittableTransaction : Transaction { public void Commit(); public IAsyncResult BeginCommit( AsyncCallback asyncCallback, object asyncState); public void EndCommit(IAsyncResult asyncResult); public CommittableTransaction(); public CommittableTransaction(TimeSpan timeout); public CommittableTransaction(TransactionOptions options); }

public struct TransactionOptions { public TimeSpan Timeout { get; set; } public IsolationLevel IsolationLevel { get; set; } }


.NET 2.0 Manual Transactions .NET 2.0 Manual Transactions -- Example Example

static void Main(string[] args) { CommittableTransaction cTx = new CommittableTransaction(); // Set the ambient Tx. Call Clone so that only we can // commit the Tx. Transaction.Current = cTx.Clone(); try { Task1(); Task2(); cTx.Commit(); } catch { cTx.Rollback(); } }

Clone returns an ITransactionreference. Therefore, the Txcannot be committed using this object.










.NET 2.0

Indigo



Participates when neededTransactional NTFS

(Longhorn?)Transactional NTFS

(Longhorn?)


.NET 2.0 Implicit Transactions .NET 2.0 Implicit Transactions

Most developers will use implicit transactions– TransactionScope + "using" establishes a transaction context– Call Complete() to indicate that you are happy with results– On Dispose, TransactionScope will commit if you called Complete(),

or abort otherwise.

You can nest TransactionScopes– Similar to serviced component, you can choose to use the current

transaction, or create a new one



TransactionScopepublic class TransactionScope : IDisposable { public TransactionScope(); public TransactionScope(TransactionScopeOption scopeOption); public TransactionScope(Transaction transactionToUse, TimeSpan scopeTimeout); public TransactionScope(Transaction transactionToUse); public TransactionScope(TransactionScopeOption scopeOption, TimeSpan scopeTimeout); public TransactionScope(TransactionScopeOption scopeOption, TransactionOptions transactionOptions); public void Complete(); public void Dispose(); }



TransactionScopeOptionpublic class TransactionScope : IDisposable { public TransactionScope(); public TransactionScope(TransactionScopeOption scopeOption); public TransactionScope(Transaction transactionToUse, TimeSpan scopeTimeout); public TransactionScope(Transaction transactionToUse); public TransactionScope(TransactionScopeOption scopeOption, TimeSpan scopeTimeout); public TransactionScope(TransactionScopeOption scopeOption, TransactionOptions transactionOptions); public void Complete(); public void Dispose(); }

public enum TransactionScopeOption { Required, RequiresNew, Suppress }

Suppresses ambient Tx in scope. RMs will not enlist.


Using Using TransactionScopeTransactionScope

static void RunImplicitTx() { using (TransactionScope ts = new TransactionScope()) { Update1(); Update2(); Update3(); ts.Complete(); } }

Any System.Tx aware RMs auto enlist in ambient Tx

Default TxScopeOption is "Required"

If we get here, we are happy

Calls TxScope.Dispose()


Using Using TransactionScopeTransactionScope

TransactionScope.Dispose(): pseudo-code

If (User did not call Complete())

Rollback current Tx

else if (this scope created current Tx))

Commit current Tx

else

Call Complete() on current Tx, Pop Txstack


Nesting Transaction ScopesNesting Transaction Scopes

using (TxScope ts = new TxScope()) { ... }

Dependent TxDependent Txusing (TxScope ts = new TxScope()) { ... }


PushPushPush Dependent TxDependent Tx

Committable TxCommittable Tx


Nested Scopes Nested Scopes –– Happy ScenarioHappy Scenario




ts.Complete()

Complete()

Dependent TxDependent Tx






ts.Complete()

Complete()





Committable Tx

ts.Complete()

Commit()

Updates performed under this Tx and all dependent Txs are committed.


Nested Scopes and Requires NewNested Scopes and Requires New




PushPush

PushCommittable TxCommittable Tx


using (TxScope ts = new TxScope( RequiresNew)) { ... }









ts.Complete()

Complete()







ts.Complete()

Commit()

Updates performed under this Tx and all dependent Txs are committed.





ts.Complete()

Commit()

Updates performed under this Tx are committed.


TxTx Scenario 1: Single DB Update Scenario 1: Single DB Update

static void SingleDBUpdate() { using (SqlConnection cnn = new SqlConnection(ConnString)) { cnn.Open(); SqlTransaction tx = cnn.BeginTransaction(); // Must associate tx with each SQL command. SqlCommand update1 = new SqlCommand("DELETE ...", cnn, tx); SqlCommand update2 = new SqlCommand("INSERT ...", cnn, tx); try { update1.ExecuteNonQuery(); update2.ExecuteNonQuery(); tx.Commit(); } catch { tx.Rollback(); } } }


TxTx Scenario 1 using .NET 2.0 Scenario 1 using .NET 2.0

static void SingleDBUpdate() { using (TransactionScope ts = new TransactionScope()) { using (SqlConnection cnn = new SqlConnection(ConnString)) { cnn.Open(); SqlCommand update1 = new SqlCommand("DELETE ...", cnn); SqlCommand update2 = new SqlCommand("INSERT ...", cnn); update1.ExecuteNonQuery(); update2.ExecuteNonQuery(); ts.Complete(); } } }

No need to Begin/Commit/Rollback Tx

No try/catch/finally

No special ctor used to associate commands with Tx

No performance penalty when using PSPE (SQL 2005)


TxTx Scenario 2: Multi DB Update Scenario 2: Multi DB Update

[Transaction(TransactionOption.Required)] public class Mover : ServicedComponent { [AutoComplete] public void Move() { using(SqlConnection cnnDB1 = new SqlConnection(Database1), cnnDB2 = new SqlConnection(Database2)) { SqlCommand cmdDeleteDB1 = new SqlCommand("DELETE ...", cnnDB1); SqlCommand cmdInsertDB2 = new SqlCommand("INSERT ...", cnnDB2); // ADO.NET connections automatically enlist into // the DTC transaction cnnDB1.Open(); cnnDB2.Open(); cmdDeleteDB1.ExecuteNonQuery(); cmdInsertDB2.ExecuteNonQuery(); } } }

Remember these issues …• Must derive from ServicedComponent• Must be in strong named assembly• Must register in COM+• Very different from single DB scenario

Remember these issues …• Must derive from ServicedComponent• Must be in strong named assembly• Must register in COM+• Very different from single DB scenario


TxTx Scenario 2 Using .NET 2.0 Scenario 2 Using .NET 2.0

public class Mover { public void Move() { using (TransactionScope ts = new TransactionScope()) { using (SqlConnection cnnDB1 = new SqlConnection(Database1), cnnDB2 = new SqlConnection(Database2)) { SqlCommand cmdDeleteDB1 = new SqlCommand("DELETE ...", cnnDB1); SqlCommand cmdInsertDB2 = new SqlCommand("INSERT ...", cnnDB2); cnnDB1.Open(); cnnDB2.Open(); cmdDeleteDB1.ExecuteNonQuery(); cmdInsertDB2.ExecuteNonQuery(); ts.Complete(); } } } }



public class Mover { public void Move() { using (TransactionScope ts = new TransactionScope()) { using (SqlConnection cnnDB1 = new SqlConnection(Database1), cnnDB2 = new SqlConnection(Database2)) { SqlCommand cmdDeleteDB1 = new SqlCommand("DELETE ...", cnnDB1); SqlCommand cmdInsertDB2 = new SqlCommand("INSERT ...", cnnDB2); cnnDB1.Open(); cnnDB2.Open(); cmdDeleteDB1.ExecuteNonQuery(); cmdInsertDB2.ExecuteNonQuery(); ts.Complete(); } } } }

No need to derive from ServicedComponent

Assembly does not need to be strong named

No special registration requirements

Code is not much different from the single DB scenario

No performance penalty compared to ES (still uses DTC)


TxTx Scenario 3: DB + Volatile Update Scenario 3: DB + Volatile Update

[Transaction(TransactionOption.Required)] public class Mover : ServicedComponent { [AutoComplete] public void Move(object key) { object val = hashTable[key]; hashTable.Remove(key); using(SqlConnection cnnDB2 = new SqlConnection(Database2)) { // Insert value from hash table into DB SqlCommand cmdInsertDB2 = new SqlCommand("INSERT ...", cnnDB2); cnnDB2.Open(); cmdInsertDB2.ExecuteNonQuery(); } } } What happens if the DB update fails?

The hashtable value is lost!What happens if the DB update fails?The hashtable value is lost!



public class VolatileToDBMover { // Does not exist, but not too hard to implement TransactedHashtable txHashtable = new TransactedHashtable(); public void Move(object key) { using (TransactionScope ts = new TransactionScope()) { object val = txHashtable[key]; txHashtable.Remove(key); using (SqlConnection cnnDB2 = new SqlConnection(Database2)) { // Insert value from hash table into DB SqlCommand cmdInsertDB2 = new SqlCommand("INSERT ...", cnnDB2); cnnDB2.Open(); cmdInsertDB2.ExecuteNonQuery(); ts.Complete(); } } } }


TxTx Scenario 3 Using .NET 2.0 Scenario 3 Using .NET 2.0 public class VolatileToDBMover { // Does not exist, but not too hard to implement TransactedHashtable txHashtable = new TransactedHashtable(); public void Move(object key) { using (TransactionScope ts = new TransactionScope()) { object val = txHashtable[key]; txHashtable.Remove(key); using (SqlConnection cnnDB2 = new SqlConnection(Database2)) { // Insert value from hash table into DB SqlCommand cmdInsertDB2 = new SqlCommand("INSERT ...", cnnDB2); cnnDB2.Open(); cmdInsertDB2.ExecuteNonQuery(); ts.Complete(); } } } }

Transacted hash table enlists in ambient Tx

Remove is rolled back if the Tx fails


Developing a Resource ManagerDeveloping a Resource Manager

In the future, MS will provide transaction aware versions of– System.Collections, System.IO, etc.– Other managed data providers (not just SqlClient)

But, .NET 2.0 provides facilities for implementing a custom RM– Implement IEnlistmentNotification for auto enlistment, rollback and

commit behavior

More help is coming in Longhorn– Transactional NTFS, Windows Logging System (WinLS)– System.Transactions.Recovery, System.Transactions.Isolation


Best PracticesBest Practices

Avoid using manual transactions; use TransactionScopeinstead

Don't create a TransactionScope outside of a using block– Not disposing a TransactionScope can leave pending Tx locks in

the database

For best performance, consider using SqlTransactionagainst a single SQL Server 2000 (no DTC)

Use System.Transactions for SQL Server 2005 and multi DB updates

For a common, simple Tx programming model use TransactionScope


SummarySummary

Huge Tx improvements in .NET 2.0 – Simple programming model– Starts fast with the LTM; stays in the LTM if volatile RM– Automatically promotes transaction when needed– Support for building custom RMs

More transaction features on the way– Declarative transactions in Indigo– Base and helper classes for easier custom RM development

(System.Transactions.Isolation, System.Transactions.Recovery)– More OS support: Transactional NTFS, Transactional Registry,

Windows Logging System

Use more transactions in your applications!– Transactions are not just for databases anymore

Questions? Comments? [email protected]


About Intertech TrainingAbout Intertech Training

Developer training delivered by the expertsOur siteYour siteOn the Web

Web Course Live

– Virtual training delivered live by our expert instructors

– Ask questions, work on labs, never leave your desk

– All you need is a browser and a phone (headset recommended)

www.IntertechTraining.com

Technology

NET Transactions Training