Intro to System.Transactions
The .NET Framework v2 has been around for a while now. Since I only started working in the world of .NET about a year and a half ago I have spent alot of time playing catch up and getting up to speed with v1.1 before I move onto v2, so there are still quite a few things in v2 I havent had a chance to look at in as much detail as I would have liked to.
So, recently I thought I would take a look at what the System.Transactions namespace is all about.
Here are the three links that were pretty much all I needed to get started, they talk about System.Transactions, Resource Managers, Transaction Managers etc.:
System.Transactions: Let's get transactional! Mitch Denny's Blog
System.Transactions and ADO.NET 2.0
Introducing System.Transactions in the .NET Framework 2
After reading the stuff above, one thing that confused me a little was...how many records would you expect to be written to the database with the code below:
Well, the answer is one. Only the second row (the one in the outerScope) will be written. Why? I hear you ask, because the innerScope is using the same transaction that the outerScope is using.
What's happening is, since we havent given any arguments in the constructor of the innerScope, the default behaviour is to either use a current transaction or to create a new one if none exists. This is the same as passing in TransactionScopeOption.Required to the innerScope constructor. The current transaction is created by the outerScope and so that is used. Again, this can be controlled by the constructors of the TransactionScope class.
When the end of the innerScope's using statement is reached, the status of the current transaction changes to Aborted and so, the second insert statement is no longer running within a transaction and so is written to the database even though outerScope.Complete() is not called.
You can check the status of the current transaction by using the
System.Transactions.Transaction.Current.TransactionInformation.Status property.
What would happen if I called outerScope.Complete() before the end of the outerScope using statement? Well, you would get a TransactionAbortedException and the second insert statement would still be written to the database.
So, recently I thought I would take a look at what the System.Transactions namespace is all about.
Here are the three links that were pretty much all I needed to get started, they talk about System.Transactions, Resource Managers, Transaction Managers etc.:
System.Transactions: Let's get transactional! Mitch Denny's Blog
System.Transactions and ADO.NET 2.0
Introducing System.Transactions in the .NET Framework 2
After reading the stuff above, one thing that confused me a little was...how many records would you expect to be written to the database with the code below:
Well, the answer is one. Only the second row (the one in the outerScope) will be written. Why? I hear you ask, because the innerScope is using the same transaction that the outerScope is using.
What's happening is, since we havent given any arguments in the constructor of the innerScope, the default behaviour is to either use a current transaction or to create a new one if none exists. This is the same as passing in TransactionScopeOption.Required to the innerScope constructor. The current transaction is created by the outerScope and so that is used. Again, this can be controlled by the constructors of the TransactionScope class.
When the end of the innerScope's using statement is reached, the status of the current transaction changes to Aborted and so, the second insert statement is no longer running within a transaction and so is written to the database even though outerScope.Complete() is not called.
You can check the status of the current transaction by using the
System.Transactions.Transaction.Current.TransactionInformation.Status property.
What would happen if I called outerScope.Complete() before the end of the outerScope using statement? Well, you would get a TransactionAbortedException and the second insert statement would still be written to the database.
posted by Nev at
2:03 pm
|
0 comments
