The TransactionScope expects a call to its Complete method as follows. Otherwise the transaction will not be committed.
using(TransactionScope scope = new TransactionScope())
{
/* Perform transactional work here */
scope.Complete();
}
Wouldn't an implementation that assumes success have been more appropriate? This would mean that less code would be required in the standard case (success).
In the case of an exception or a call to a method such as 'Rollback' (this method does not currently exist) the transaction could be rolled back.
using(TransactionScope scope = new TransactionScope())
{
/* Perform transactional work here */
if(problemOccurred)
{
scope.Rollback();
}
}
Note that the problemOccurred flag would only be required in cases where the problem did not result in an exception. In this case, the rollback would be performed automatically.
I am interested in gaining further insight into why this implementation was used.
Update: A couple of the answers so far argued that a try-catch block would be required if the implementation that I described were used. This is not the case. The transaction is automatically rolled back when an exception is not handled within the using block. This is the case in both the existing implementation and the one that I described. See 'Completing a transaction scope' section here for further details.
Update 2: I finally understand what was being explained in the answers. This is not a language construct that could have been interpreted any way that the language designers saw fit - it is an implementation of the IDisposable pattern. Without the call to Complete the code within the Dispose method would have no knowledge of whether it is being called as the result of the code within the using block being executed successfully or because an exception occurred. I was imagining something similar to the following where both transaction and rollback are keywords.
transaction
{
/* Perform transactional work here */
if(problemOccurred)
{
rollback;
}
}
This would of course present problems if transaction options need to be passed to the TransactionScope.
TransactionScope provides an implicit programming model in which the transactions are automatically managed by the infrastructure. It provides a simple mechanism for you to specify a code block to participate in a transaction.
TransactionScope reduces the complexity of code and thus it is widely accepted and used in custom software development. The TransactionScope makes the block of code as a part of a transaction without requesting c# developers to connect with the transaction itself.
The ambient transaction is the transaction that is present in the thread that the current application code is executing within. To obtain a reference to the ambient transaction call the static Current property of Transaction: <em>Transaction ambientTransaction = Transaction.Current;</em>
Definition: TransactionalScope makes your code block Transactional. You can easily maintain one transaction for multiple databases or a single database with multiple connectionstrings, using TransactionScope. When you use TransactionScope there is no need to close any Database connections in the middle.
This way, every transaction would look like this:
using(TransactionScope scope = new TransactionScope())
{
try
{
/* Perform transactional work here */
}
catch (Exception)
{
scope.Rollback();
throw;
}
}
Which is more code.
Edit:
Everything else is risky or bad style. You have to be absolutely sure that there wasn't any error when committing. When leaving the using block, you don't know if you leave it because an exception is thrown or because you just reached the end of it. When calling Complete
, you know.
The transaction block syntax is already the simplest you can do. Just implement the transaction without any special error handling and commit it at the end. You don't have to care and rolling back when any error occurs. Consider, exceptions can be thrown in almost every single line of code (eg. NullReference, Overflows, InvalidOperation etc). So what could be easier than this?
It means that you don't need to put a manual try/finally (or catch) block (possibly with a "success" flag) in for the failure case. Try rewriting the above code to roll back on error, and look at how much messier it is...
Basically the normal desired behaviour is to only commit if it reaches the end of the block with no exceptions. The simplest way of achieving that is to put a method call to signify success at the end of the block.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With