Transaction not connected, or was disconnected

[cst]

Hi,

I have a problem, i get this error:

NHibernate.TransactionException: Transaction not connected, or was
disconnected
at NHibernate.Transaction.AdoTransaction.CheckNotZombied()
at NHibernate.Transaction.AdoTransaction.Rollback()

Usually it happens once every 2 days in production, but somehow im
getting it consistently in our test enviroment right now.

Im at a loss, to whats wrong. Any ideas? Somehow i can get more info??

Regards,
CSkydt

[Frans Bouma]

I was writing the 'what's a zombied ado.net transaction' story here
and then I saw this occurs inside the nhibernate code. :)

Do you share the session among threads (or asp.net requests) ? If
you look at the AdoTransaction class in the nhibernate sourcecode,
CheckNotZombied only throws if 'trans' is null or its connection object is
null, both are never set in the class itself, so its only triggered to throw
if another thread has set 'begun' to true and after that the rollback is
called.

Although it is indeed weird. Do you experience exceptions due to fk
constraint checks ? these roll back the transaction on the server (creating
a zombied ado.net transaction) which might trigger this too...

FB

[cst]

Thanks for the answer.

You were right about the constrain checks.

Some database schema update scripts was poorly written, and the actual
error was hidden.

Thanks for leading me in the right direction.

[Seif Attar]

I am having the same problem, looking at the log files, I see that a
deadlock occurred "Transaction (Process ID 77) was deadlocked on lock
resources with another process and has been chosen as the deadlock victim.
Rerun the transaction." I guess when a transaction deadlock occurs it
releases the connection. Do you have Nhibernate logging enabled? Did you
have a look in your log file? I don't know if there is an easier way to get
more info, I resort to the log file! :)

Hi,

Regards,
CSkydt

--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to
nhusers+u...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.

[Frans Bouma]

When you run into a 'zombied' transaction, it almost always means either one
of two things:
1) you shared the transaction object among threads
or
2) the RDBMS rolled back the transaction by itself due to a severe error.

Point 1) is rare, but it could happen if you share things among asp.net
requests for example.

point 2) is more obscure. Every RDBMS at some point decides to roll back the
active transaction if an error occurs of a given severity level. Looking at
your deadlock remark, it sounds like sqlserver. SQL Server rolls back a
transaction on its own at severity level 19 or higher if I'm not mistaken.
You can lookup the severity level of a T-SQL error in the SQL Server books
online. If the error has a severity level of 19 or higher the current
'batch' is stopped and rolled back.

Looking at the deadlock error (1205) it seems it's severity level 13. So it
doesn't automatically rollback the transaction in the database.

however, that doesn't mean NHibernate doesn't do that for you. So you also
have to check whether you properly handle the error and continue/retry the
whole batch properly.

FB

[Berke]

Why doesn't the nHibernate transaction object's IsActive property look at the connection to determine if its still active?