Transaction Aborted - Timeout inmediato

[Hernan Garat]

Buenas tardes a todos,

Estamos teniendo una situación en la aplicación que luego de buscar
largo tiempo, y realizar distintas pruebas, me veo obligado a
consultar para encontrar una solución al problema.

La aplicación, utiliza MSDTC, y TransactionScope. En producción el
error apareció luego de 4 días (en desarrollo nunca, hasta el
momento). Durante largo tiempo (1 o 2 horas), de forma aleatoria, los
usuarios recibían un error en la aplicación. A veces podían ingresar y
otras veces no. Al analizar el error que se producía, era un
Transaction Aborted. Lo llamativo es que sucedía a veces, y a veces
no.
Suponíamos que el error se debía a micro cortes en la conexión, o
problemas de recursos en la base de datos (Memoria, disco, procesador,
etc).
Luego de verificar que la base de datos se encontraba perfecta,
analizamos el servidor web. Se reinicio el IIS, y todo volvió a la
normalidad, por 4 días aproximadamente, cuando luego volvió a fallar.
Todo se volvió mas interesante cuando sucedió 1 vez en una maquina de
desarrollo local.
Se aprovecho el momento, ya que replicarlo es casi imposible. Se bajo
el servicio del msdtc, y el error seguía, se cerraron los web server
virtuales del visual studio, y el error seguia. Cerramos el visual
studio, y al iniciar la aplicacion nuevamente sucedia. Se apago el
equipo, y se volvió a encender, y no sucedió nunca mas.
No logramos replicarlo hasta el momento, pero en produccion sigue
sucediendo.

La linea de codigo que tira la excepcion es la siguiente:

TransactionScope = new System.Transactions.TransactionScope(
TransactionScopeOption.Required, new
TransactionOptions()
{
IsolationLevel =
System.Transactions.IsolationLevel.ReadCommitted
});


La Excepcion es la siguiente:

System.Transactions.TransactionAbortedException: The transaction has
aborted. ---> System.TimeoutException: Transaction Timeout
--- End of inner exception stack trace ---
at
System.Transactions.TransactionStateAborted.CreateAbortingClone(InternalTransaction
tx)
at System.Transactions.DependentTransaction..ctor(IsolationLevel
isoLevel, InternalTransaction internalTransaction, Boolean blocking)
at
System.Transactions.Transaction.DependentClone(DependentCloneOption
cloneOption)
at System.Transactions.TransactionScope.SetCurrent(Transaction
newCurrent)
at
System.Transactions.TransactionScope..ctor(TransactionScopeOption
scopeOption, TransactionOptions transactionOptions)
at SanWF.Common.Linq.Context.ContextGroupManager.BeginTransaction()
in c:\Santillana\repo\tag_1.2\SanWF\SanWF\SanWF.Common\Linq\Context
\ContextGroupManager.cs:line 272
at
SanWF.Common.Linq.Context.ContextGroupManager.Create[TDataContext]
(String configName) in c:\Santillana\repo\tag_1.2\SanWF\SanWF
\SanWF.Common\Linq\Context\ContextGroupManager.cs:line 140
at SanWF.Soluciones.Compras.Web.Global.Global_BeginRequest(Object
sender, EventArgs e) in c:\Santillana\repo\tag_1.2\solucion\no-
reutilizable\SanWF.Soluciones\SanWF.Soluciones.Compras
\SanWF.Soluciones.Compras.Web\Global.asax.cs:line 85
at
System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
Boolean& completedSynchronously)


Realizamos varias pruebas, generamos un timeout en el commit, pero el
stacktrace es otro. aca el error se produce al crear en transaction
scope.

Saludos y gracias.

[Carlos Peix]

Estimados,

Finalmente encontramos el problema que causaba este compoetamiento, me parece bueno compartirlo para beneficio de todos.

La aplicacion esta usando el objeto TransactionScope para coordinar transacciones entre dos bases de datos. Dado que ya estabamos manejando la sesion del ORM (Linq2Sql) en inicio y fin de request, hicimos lo propio con el TransactionScope, iniciandolo en el BeginRequest y el dispose en el EndRequest.

El problema es que TransactionScope no esta preparado para eso, evidentemente utiliza variables internas de tipo ThreadStatic, por lo que dene cumplir todo su ciclo de vida (al menos mientras se interactua con el) en el mismo trhead.

Como ha es sabido, ASP.NET no garantiza el mismo thread para todo el request. Nosotros previmos eso almacenando la instancia de TransactionScope en el estado del request, pero al hacer el dispose en otro thread, las variables threadstatic simplemente no estaban presentes, estaban en "otro lado" y asi quedaban asociadas al thread.

Cuando caia un request, probablemente minutos despues, en el mismo thread, se encontraba con un trnansaction scope "envenenado" con variables thread static "viejas".

Encontramos un workaround, que es utilizar unos handlers especificos (no recuerdo exactamente el nombre ahora, pero empiezarn con pre y con post) que garantizan el uso del mismo thread en todo el ciclo de vida, siempre y cuando no se llame a Response.Redirect con el ultimo parametro en true.

Moraleja: usen TransactionScope con un using () {}, estrictamente.

Luego encontraremos algo mejor.

Un saludo

----------------------------------
Carlos Peix

2012/1/26 Hernan Garat <garat....@gmail.com>

--
Desuscripción: altnet-argenti...@googlegroups.com

[Jorge Rowies]

Hola Carlos, quizás esté diciendo una pavada, pero me parece que usar DependentTransaction puede servir:

http://msdn.microsoft.com/en-us/library/system.transactions.dependenttransaction.aspx
http://msdn.microsoft.com/en-us/library/ms229976.aspx

Saludos

2012/2/11 Carlos Peix <carlo...@gmail.com>

--
Desuscripción: altnet-argenti...@googlegroups.com

[Carlos Peix]

Hola Jorge,

Gracias por el dato. Vamos a investigarlo pero sospecho que sera complicado de aplicar puesto que no tenemos control de los threads a los que esta expuesto el objeto.

Un abrazo

----------------------------------
Carlos Peix

2012/2/12 Jorge Rowies <jorge....@gmail.com>

--
Desuscripción: altnet-argenti...@googlegroups.com

[Alberto T. Payero Mota]

Interesante el tema, luego me detendre a verificar esto.

En otro orden, necesito comunicarme con uno de los miembros de la comunidad, el Sr. Matias thacker, si alguien sabe como puedo contactarle me dejan saber o con el Sr. Matias Britos, Arquitecto de Desarrallo de la empresa white works, si alguien tiene los numero de esta empresa me deja saber.

Saludos cordiales,

2012/2/15 Carlos Peix <carlo...@gmail.com>

--
Desuscripción: altnet-argenti...@googlegroups.com

--

Alberto T. Payero Mota, Administrador de Proyectos |E-mail: atpa...@gmail.com | Cel. 809.604.2753 
 
Salmos 50:23  El que sacrifica alabanza me honrará; Y al que ordenare su camino, Le mostraré la salvación de Dios.
 
Proverbios 28: 14 Bienaventurado el hombre que siempre teme a Dios,
pero el que endurece su corazón caerá en el mal.

Salmos 27:13 Hubiera yo desmayado, si no creyese que veré la bondad de Jehová  En la tierra de los vivientes.

Salmos 27:14 Aguarda a Jehová;
    Esfuérzate, y aliéntese tu corazón;
    Sí, espera a Jehová.