Well, AFAIK the NH transaction is automatically rolled back in the dispose so there is no need to explicitly call Rollback on the nhibernate transaction but it should not result in e exceptions.
Just looking at the NSB code at https://github.com/NServiceBus/NServiceBus/blob/master/src/nhibernate/UnitOfWork/NServiceBus.UnitOfWork.NHibernate/UnitOfWorkManager.cs var session = CurrentSessionContext.Unbind(SessionFactory); using (session) using (session.Transaction) { if (!session.Transaction.IsActive) return; if (ex != null) session.Transaction.Rollback(); else session.Transaction.Commit(); } They perform an explicit rollback as you mentioned. Are you maybe also using NHibernate within you own message handlers or saga's? -- Ramon On Tue, Apr 30, 2013 at 2:34 PM, Johannes Gustafsson <[email protected]>wrote: > I have discovered that if NH throws certain exceptions and you after that > explicitly rolls back the NH transaction (like NSB does), then it will > consistently corrupt the connection pool. Removing the explicit rollback > makes the problem go away, at least in this specific scenario. > > Example > > using (create TxScope) > using (open session) > using (begin NH.Trans) > > try { > session.QueryOver()...SingleOrDefault() // results return 2 rows which > makes NH throw > } > catch (Exception) { > nhtx.Rollback(); // Throws with message: ROLLBACK without corresponding > BEGIN > // Connection pool is now corrupt > } > > > > 2013/4/30 Yngve Nilsen <[email protected]> > >> Exactly the same problem here when running NHibernate in NServiceBus >> hosted services. In our case it doesn't have to be a deadlock, just a >> general failure within the transaction. It seems to be related to the fact >> that the SQL ConnectionPool and DTC have some issues with multithreading... >> Would be awesome to see a fix for this in NHibernate, since I don't think >> the underlying MSDTC or SqlConnectionPool is going to be changed anytime >> soon. >> >> >> On Friday, October 19, 2012 2:21:39 PM UTC+2, Roy Jacobs wrote: >>> >>> Hi all, >>> >>> I see quite a few bugs on JIRA relating to the same topic: >>> https://nhibernate.jira.com/**secure/IssueNavigator.jspa?** >>> reset=true&jqlQuery=labels+%**3D+TransactionScope<https://nhibernate.jira.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+TransactionScope> >>> >>> They're all about the fact that SQL errors cause a session's >>> SqlConnection to be closed from a different thread than the thread that >>> opened it (through the AdoNetDistributedTransacionFac**tory). We've >>> been running into this issue for quite some time now as well. We store >>> NServiceBus saga's using NHibernate and occasionally we may get a deadlock. >>> Normally this would not be a huge problem (just retry the message), but >>> once this deadlock occurs, we get, for a minute or 2, a log full of errors >>> like "New request is not allowed to start because it should come with valid >>> transaction descriptor" and "Distributed transaction completed. Either >>> enlist this session in a new transaction or the NULL transaction.". >>> >>> Now, this is something we'd like to have fixed, or fix ourselves. Is >>> anyone actively looking at this, right now? Or willing to share some >>> suggestions/findings? >>> >>> Roy >>> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nhibernate-development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > > --- > You received this message because you are subscribed to the Google Groups > "nhibernate-development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
