I'm interested to know what happens if a session's transaction is not explicitly rolled back when a session is closed or disconnected. Is it automatically rolled back? And what happens if the DB connection the session is using wasn't actually created by the session?

The reason I ask is that I want to implement an event that would be raised when a session's transaction rolls back - whether explicitly using transaction.Rollback() - or implicitly. I could then use this event to trigger cleanup operations concerning non-database resources used or created by entities that are participating in the transaction.

At the moment I'm wrapping the Transaction object and raising the event when the Rollback() method is called, but I'm not sure whether it's appropriate to raise the event when the session is closed or disconnected. I could check whether the session has a transaction and if the transaction's WasCommitted and WasRolledback properties both equal false I could raise the event, but I want to be sure I'm not going to raise it inappropriately.

Can anyone clarify?

Cheers,

Symon.

Session currently only disposes its transaction when it itself is being disposed of, i.e. when ISession.Dispose is being called. It doesn't do anything to its transaction when Close or Disconnect are being called.

Hmm. But what happens to the underlying sql transaction? If I do a close or disconnect then presumably the transaction on the connection will be auto-rollback'd, right?

I'm trying to work out at what points the transaction will be implicitly rolled back, rather than explicitly.

Symon.

I think that you should find out what an ADO.NET transaction does when it is disposed.

This post on Hibernate blog might be related: http://blog.hibernate.org/cgi-bin/blosxom.cgi/2005/10/19#popquiz_connectionclose

Ah, thanks sergey.

So essentially I guess I can't take for granted that a transaction will be rolled back...

I think I'm going to make my Transaction object wrapper do an explicit rollback on dispose if it hasn't been rolled back or committed.

I'm trying to set up a nested transaction arragement where I can get the participants to subscribe to a "rolling back" event. If the main transaction or any nested transaction does a rollback, or the session or connection is closed/disposed while a transaction is in progress then I want to roll back the DB transaction (since, of course ADO.NET only actually allows one) and then raise the event.

I've set up an event helper to reverse the order in which the event handlers will fire so that the inner-most nested transaction participants will have their handler called first and each participant can use this handler clean up any non-db related resources they've used.

I think I've basically got it in the bag (unless there's something stupid I'm doing here that you can point out!), but it'd be much nicer if there were REAL nested transactions so you could just back out a sub-segment without having to kill the whole transaction from the top down.

Dumb idea?

Symon.