Geek Answers Handbook

How is all the code inside the TransactionScope block not executed until the scope is fixed or canceled?

I read about TransactionScope and this article, but I still don't understand 2 things:

  • When SqlCommand.ExecuteNonQuery is executed, is it really not executed until scope.Complete() called? If so, then where are all the operations that were performed within the scope left and waiting for scope.Complete() or scope.Rollback() ?
  • When a TransactionScope is created, how does it prevent SqlCommand.ExecuteNonQuery from executing and wait for scope.Complete() or scope.Rollback() ? Does this create some kind of "place" and does SqlCommand somehow know about it and put instructions there?
+4
source share
4 answers

[1] When SqlCommand.ExecuteNonQuery is executed, it really is not executed until the .Complete () area is called?

No, this is not true. Your command is executed on the line where you call ExecuteNonQuery . It is interesting, however, to know where all the changes are stored. The changes do not go directly to the affected tables on the server side, but the changes are saved in a temporary place (again on the server side), which leads to the answer to your second question.

[2] When a TransactionScope is created, how does it prevent SqlCommand.ExecuteNonQuery from executing and wait for scope.Complete () or scope.Rollback ()?

This does not prevent, as such, the action is performed, but since the result of the action is stored in a temporary place, you must either combine these changes with the main table (s) - scope.Commit() , or discard these changes - scope.Rollback() ( or whatever is used to discard changes to a particular database data provider)

+5
source

TransactionScope hides a lot of things under the covers.

When you create a TransactionScope, everything you do inside it is in the database transaction (transaction) context. Thus, SQL statements will be executed immediately, but their effects will be inside the transaction, so that other processes do not know about them that occurred before the transaction.

If you work with only one database, then the transaction is open against it and committed or canceled according to whether you are .Complete () or not. Also, if an exception occurs in the context of a TransactionScope, the transaction is rolled back.

If you work with multiple databases, each transaction is created, and Microsoft Distributed Transaction Coordinator (MSDTC) manages the overall transaction. When you .Complete () MSDTC then instruct each individual transaction to complete.

Note. MSDTC is not limited to databases - see here for more information.

+1
source

The scope of transactions does not impede code execution; it prevents a transaction. Thus, in the case of SqlCommand.ExecuteNonQuery , since it is inside the transaction, SqlCommand looks at the transaction coordinator and sees that it was called inside the transaction, so when it connects to SQL Server, the transaction is supported by SQL, so SQL writes data to the database but not readable unless the transaction is committed (or someone does a dirty read). If complete is never called, then when placing the TransactionScope it rolls back, and SQL can cancel the insert (or something else that it did).

Anything that uses transactions (such as other database technologies) must implement its .Net code to support transactions.

Transactions are essentially used in databases, but theoretically, other code can be used to support it.

But, to answer your question, the code does not stop before calling the Complete() method, it starts, but inside the transaction.

0
source

This can help you with questions that you can enable tracing for MSDTC to see the transaction.

For more details see the link http://support.microsoft.com/kb/899115

Hope this helps.

0
source

More articles:


All Articles