Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It should be noted that when using the <a href="http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.aspx" rel="noreferrer"><code>TransactionScope</code></a> there is no need for the <code>try/catch</code> construct you have. You simply have to call <a href="http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.complete.aspx" rel="noreferrer"><code>Complete</code></a> on the scope in order to commit the transaction when the scope is exited.</p> <p>That being said, <code>TransactionScope</code> is usually a better choice because it allows you to nest calls to other methods that might require a transaction without you having to pass the transaction state around.</p> <p>When calling <a href="http://msdn.microsoft.com/en-us/library/xfh66ye8.aspx" rel="noreferrer"><code>BeginTransaction</code></a> on the <a href="http://msdn.microsoft.com/en-us/library/system.data.common.dbconnection.aspx" rel="noreferrer"><code>DbConnection</code></a> object, you have to pass that transaction object around if you want to perform other operations in the same transaction, but in a different method.</p> <p>With <code>TransactionScope</code>, as long as the scope exists, it will handle everything that registers with the current <a href="http://msdn.microsoft.com/en-us/library/system.transactions.transaction.aspx" rel="noreferrer"><code>Transaction</code></a> on the thread, making your code cleaner, and more maintainable.</p> <p>On top of that, you have the added benefit of being able to use other resources that can participate in transactions, not just the connection to the database.</p> <p>It should be noted that in situations where you need to squeeze the most out of your connections and database operations, you might not want to use <code>TransactionScope</code>; even against a single database, you run the possibility of the Distributed Transaction Coordinator being used and having the transaction being turned into a distributed transaction (even for a single database connection).</p> <p>In these cases, while muddying up your design, you might want to consider passing a connection-specific transaction around.</p> <p><em>Or</em>, if you know you will use one resource consistently (and on the same thread), you might want to create a class that reference-counts your connection/transaction.</p> <p>You would create a class that on construction, creates your resource/increments the count. It would also implement <a href="http://msdn.microsoft.com/en-us/library/system.idisposable.aspx" rel="noreferrer"><code>IDisposable</code></a> (in which you would decrement/release/commit/abort when the count is zero), and store the count in a variable that has <a href="http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx" rel="noreferrer"><code>ThreadStaticAttribute</code></a> applied to it.</p> <p>This allows you to separate the transaction management from the logic code, and still hold onto a singular resource fairly efficiently (instead of escalating to a distributed transaction).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload