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