What is the practical use of System.Transactions?

Question

I saw the System.Transactions namespace and am wondering if I can do RDMBS with this namespace use?

But when I saw a few examples, I don’t understand how System.Transactions does anything other than just trying to catch and get the result of success / failure?

This is an example on the MSDN website, I know that it can be very simple, but I can’t understand the benefits of this example, can someone tell me what is the difference between a simple try / catch and a transaction scope in this next an example.

If I have to create RDBMS (create my own RDMBS), I understand that we need to write a lot of logs to the disk of operations that we perform, and in the end we will cancel these operations in case of rollback, but it doesn’t cost anything to destroy anything.

// This function takes arguments for 2 connection strings and commands to create a transaction // involving two SQL Servers. It returns a value > 0 if the transaction is committed, 0 if the // transaction is rolled back. To test this code, you can connect to two different databases // on the same server by altering the connection string, or to another 3rd party RDBMS by // altering the code in the connection2 code block. static public int CreateTransactionScope( string connectString1, string connectString2, string commandText1, string commandText2) { // Initialize the return value to zero and create a StringWriter to display results. int returnValue = 0; System.IO.StringWriter writer = new System.IO.StringWriter(); try { // Create the TransactionScope to execute the commands, guaranteeing // that both commands can commit or roll back as a single unit of work. using (TransactionScope scope = new TransactionScope()) { using (SqlConnection connection1 = new SqlConnection(connectString1)) { // Opening the connection automatically enlists it in the // TransactionScope as a lightweight transaction. connection1.Open(); // Create the SqlCommand object and execute the first command. SqlCommand command1 = new SqlCommand(commandText1, connection1); returnValue = command1.ExecuteNonQuery(); writer.WriteLine("Rows to be affected by command1: {0}", returnValue); // If you get here, this means that command1 succeeded. By nesting // the using block for connection2 inside that of connection1, you // conserve server and network resources as connection2 is opened // only when there is a chance that the transaction can commit. using (SqlConnection connection2 = new SqlConnection(connectString2)) { // The transaction is escalated to a full distributed // transaction when connection2 is opened. connection2.Open(); // Execute the second command in the second database. returnValue = 0; SqlCommand command2 = new SqlCommand(commandText2, connection2); returnValue = command2.ExecuteNonQuery(); writer.WriteLine("Rows to be affected by command2: {0}", returnValue); } } // The Complete method commits the transaction. If an exception has been thrown, // Complete is not called and the transaction is rolled back. scope.Complete(); } } catch (TransactionAbortedException ex) { writer.WriteLine("TransactionAbortedException Message: {0}", ex.Message); } catch (ApplicationException ex) { writer.WriteLine("ApplicationException Message: {0}", ex.Message); } // Display messages. Console.WriteLine(writer.ToString()); return returnValue; } 

In the above example, what are we doing? I think the SQL Client library will do everything right? Does this mean that System.IO.StringWriter will either contain all success text or all failure text? or is there any lock between the scope of the TransactionScope?

Answer 1

First of all, TransactionScope is not the same as try / catch. TransactionScope is the name of the transaction scope. A transaction in scope must be explicitly called by a call to Complete in scope. Any other case (including an exception raised in a scope) terminates the use of a block that exposes the scope and implicitly rolls back an incomplete transaction, but does not handle the exception.

In basic scenarios, a transaction from System.Transactions behaves the same as a db client transaction. System.Transactions provides the following additional features:

• API agnostic. You can use the same transaction scope for oracle server, sql server or web service. This is important when your transaction runs in a layer that is clueless (does not know any information about persistence implementation).
• Auto dial. If specified in the connection string (default behavior). A new database connection is automatically included in an existing transaction.
• Automatic promotion of a distributed transaction. When a second connection connects to a transaction, it automatically rises to a distillative one (MSDTC required). Promotion also works when you leverage other consistent resources, such as a transactional web service.
• and etc.

Answer 2

A transaction will make the necessary lock for you. In addition, there is an implicit rollback when a transaction is issued at the end of its scope if it was not committed using the Complete () function (as suggested by the comments). Thus, if there is an exception, all operations are automatically rolled back, and there will be no changes in the database. For example, if the second request fails, it will also undo changes to the first request.

However, for StringWriter, it will still contain messages up to failure (for example,

 Rows to be affected by command1: {0} ApplicationException Message: {0} 

may appear in your journal after this code.

Regarding the creation of an RDBMS with this class, I'm not quite sure that I understand your question. If you want to create a relational database management system, I would say that you are probably looking at the wrong place. If you mean that you want to access an RDBMS through a transaction, I would say it depends on your needs, i.e. if you need transactions that can guarantee that your applications will be executed in order and on an all-or-nothing basis, then yes, a transaction is a good place to start.