High load SqlServer failes throwing error 3926 - what is that?

It manisfests itself in our SqlClient use (i.e. .NET 2.0) on one client side only...

with dozens of messages like:

ASP.global_asax - System.Data.SqlClient.SqlException : Server failed to resume the transaction, desc: 3500000c5b.

The transaction active in this session has been committed or aborted by another session.

That poins to SQL Server error 3926.

But I have NO clue how that comes. Anyone an idea? The code works flawless under dozens of other systems.

This looks like a exception throwed by SQL engine.

Guess what - it is SQL Error 3926 indicated by SQL Server. I already found that out and I already said so.

From "The transaction active in this session has been committed or aborted by another session.", I think more than one session in your application are accessing one transaction.

No chance. Here is the problem. I have, in the complete application, exactly 8 methods that do SQL processing. EVERY ONE of them:

* Gets a connection
* Establishes a transaction
* does it's job
* Closes the transaction
* Closes the connection

There is no open transaction ever left. All conenctions are properly disposed in a finally clause of a try/catch block in the method.

In fact, all my methods look like this:

Start:

IDbConnection connection = GetConnection ();
IDbTransaction txn = null;
if (System.Transactions.Transaction.Current == null) {
txn = connection.BeginTransaction ();
}
try {

processing

} finally {
if (txn == null) {
txn.Rollback ();
txn.Dispose ();
txn = null;
}
if (connection != null) {
connection.Close ();
connection.Dispose ();
connection = null;
}

If an error would happen in the finally block, I would see it. This is the pattern ALL my methods follow. This is the only location I actually open a connection. And I have a total of 8 methods that actually use the GetConnection method - and all run through the same pattern.

That is why I am ripping my hairs out. We DO close all transactions. I do NOT reuse transactions. This stuff is as simple as it gets. How the heck CAN anything go wrong here?

Normally, you can take a sql profiler trace to find out why.

Did you actually ever try that? I said "under high load". That server is basically like processing 2000 or so sql statements a SECOND for minutes before that thing slowly starts to materialize. The error does NOT appear under low or medium load. As a matter of fact, I have been unsuccessfull in replicating it in the lab. I get it on one customer's system, and I get it occasionally on one of our hosting systems for one customer (who uses a lot of ressources). It is critical for the one customer with his own system, because I sometimes get 10 or so of those a minute. In both scenarios where the error happens I can not turn on tracing for obvious reasons. And again, in the lab I was not successfull replicating it.

But I simply am totally our of ideas on what causes this. It should just not happen.

|||Did anybody solve this problem ?