El TecnoBaúl de Kiquenet

Kiquenet boring stories

El maravilloso mundo de las Transacciones

Posted by kiquenet en 21 julio 2010

Nested Transaction Scopes

three TransactionScopeOption settings:

  • Required: the contained code depends on a transaction for atomicity, isolation, and compensation, and could be part of a broader transaction.
  • RequiresNew: the contained code depends on a transaction, but must be independently committed or rolled back.
  • Suppress: the contained code performs its own compensation, so must not be part of a transaction.

The first setting is the default, under the assumption that if you are creating a TransactionScope, you probably want a transaction. In that case, the normal situation is one where the operation you’re about to do can be reasonably integrated into a transaction that already active.

The second setting is for cases where the contained code block does require a transaction for its consistency, and provides a feature that demands that it be separate from any transaction that might already be active. One typical example would be a function that provides activity logging to, say, a database. It may be implemented such that it required a transaction to provide consistency, but it couldn’t accept an outer rollback to undo the record of the attempted activity.

The final setting, Suppress, handles case where the contained code needs to be sure that it is not executing as part of any transaction. This is fairly uncommon for a local operations — the only real case for this would be if the contained code was designed to handle its own compensation, yet used recoverable resources, such as SQL, to do its actions.

However, the reality is slightly more subtle. Complete means just what the name suggests — that the code within the TransactionScope has completed (successfully) all the operations it intended to do as part of the transaction. Note that this is also why you can’t call Complete twice. To do so would mean that at least one of the two calls wasn’t the last intended operation.

When a TransactionScope is disposed it first looks to see if it was completed successfully. If it was not, the transaction is immediately rolled back. If it was, and this was the TransactionScope that created the transaction in the first place, the transaction is committed. Finally, in both cases, the current transaction is replaced with the value that was current when the TransactionScope was created.

Thus we have, for success:

// no transaction is active here
using (TransactionScope s = new TransactionScope ())
{
    // transaction ‘a’ is active here
    using (TransactionScope t = new TransactionScope
                (TransactionScopeOption.RequiresNew))
    {
        // transaction ‘b’ is active here
        t.Complete ();
    } // the transaction from ‘s’ is put into Current.

    // transaction ‘a’ is active here
    using (TransactionScope u = new TransactionScope ())
    {
        // transaction ‘a’ is active here
        u.Complete ();
    } // the transaction from ‘s’ is put into Current.

    // transaction ‘a’ is active here
    s.Complete ();
}

// ‘a’ commits at this point
// no transaction is active here

For a failure case we have:

// no transaction is active here
using (TransactionScope s = new TransactionScope ())
{
    // transaction ‘a’ is active here
    using (TransactionScope t = new TransactionScope(
                  TransactionScopeOption.RequiresNew))
    {
        // transaction ‘b’ is active here
        t.Complete ();
    }

    // transaction ‘a’ is active here
    using (TransactionScope u = new TransactionScope ())
    {
        // transaction ‘a’ is active here
        //u.Complete ();
    } // ‘a’ rolls back here,
      //the transaction from ‘s’ is put into Current.

    // transaction ‘a’ is current, but aborted here
    s.Complete ();

}  // ‘a’ is already aborted, so is just removed at this point
// no transaction is active here

There was a massive upgrade to the error handling within SQL Server 2005. These articles are fairly extensive:

Error Handling in SQL 2005 and Later by Erland Sommarskog
http://www.sommarskog.se/error_handling_2005.html

Error Handling in SQL 2000 – a Background by Erland Sommarskog
http://www.sommarskog.se/error-handling-I.html

http://stackoverflow.com/questions/2701934/transactionscope-and-transactions

MSDN:

http://msdn.microsoft.com/en-us/library/ms973865.aspx

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: