As far as I understand, the \"correct\" way to use a TransactionScope
is to always call transactionScope.Complete();
before exiting the using
basically using statement is converted to this at compile time by the C# compiler
TransactionScope transactionScope = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = IsolationLevel.ReadUncommitted })
try
{
//your works
}
finally
{
if (transactionScope != null)
((IDisposable)transactionScope).Dispose();
}
So this is all you should expect from C# .... you just need to do your work with the TransactionScope
If the TransactionScope object created the transaction initially, the actual work of committing the transaction by the transaction manager occurs after the last line of code in the using block. If it did not create the transaction, the commit occurs whenever Commit is called by the owner of the Transaction object. At that point the transaction manager calls the resource managers and informs them to either commit or rollback, based on whether the Complete method was called on the TransactionScope object.
calling this method does not guarantee that the transaction wil be committed. It is merely a way of informing the transaction manager of your status. After calling the Complete method, you can no longer access the ambient transaction by using the Current property, and attempting to do so will result in an exception being thrown.
The using statement ensures that the Dispose method of the TransactionScope object is called even if an exception occurs. The Dispose method marks the end of the transaction scope. Exceptions that occur after calling this method may not affect the transaction. This method also restores the ambient transaction to it previous state.
A TransactionAbortedException is thrown if the scope creates the transaction, and the transaction is aborted. A TransactionInDoubtException is thrown if the transaction manager cannot reach a Commit decision. No exception is thrown if the transaction is committed.
hope this will clear for you
Yes you need to use it, that is the way to inform the compiler that you completed your tasks sucessfully, from Microsoft docs on the TransactionScope class:
When your application completes all work it wants to perform in a transaction, you should call the Complete method only once to inform that transaction manager that it is acceptable to commit the transaction. Failing to call this method aborts the transaction.
Also for the Complete method:
Failing to call this method aborts the transaction, because the transaction manager interprets this as a system failure, or exceptions thrown within the scope of transaction. However, you should also note that calling this method does not guarantee a commit of the transaction. It is merely a way of informing the transaction manager of your status.
So my question is, must it be used or not?
Complete
must be used when updates are made in order to COMMIT
the transaction. Otherwise, the transaction manger will issue a ROLLBACK
and undo changes made.
With a read-only transaction like your example, I can think of no material difference with or without Complete
. The COMMIT
or ROLLBACK
issued by the transaction manager will have the same net effect of releasing locks and resources held by the transaction in both cases.
Although it's not a requirement to invoke Complete
in a read-only transaction, it's still a best practice IMHO. Consider the poor developer who later unwittingly adds data modification code to your transaction block without seeing Complete
is missing.