Flush NHibernate whilst still allowing transaction rollback?

For the sake of formatting I allow myself to update tolism7's answer here.

For the sake of formatting I allow myself to update tolism7's answer here. Use using and forget about transaction.Dispose() - the transaction will automatically be Dispose'd of at the end of the using block. Throw - don't throw ex because it means throwing away your stacktrace (see this post where it states "When the .

NET Framework executes this statement: throw ex; it throws away all the stack information above the current function. ") . Public void CommitChanges() { using (var transaction = Session.

BeginTransaction()).

When using transactions with Nbernate try to avoid using the Session.Flush() and instead use the transaction.Commit() which it calls the session.flush() internally. If during the Commit() an error occurs and the transaction needs to be rolled back this can be addressed like this. Public static void CommitChanges() { ITransaction transaction = Session.

BeginTransaction(); try { transaction.Commit(); } catch (bernateException ex) { transaction.Rollback(); //close and dispose session here throw ex; } finally { transaction.Dispose(); } } Now, if a manual call to flush() or a call to commit() goes through successfully there isn't a way to roll back the transaction using N Especially when calling the transaction.Commit() command the AdoTransaction created by Nbernate is then disposed right after the Commit() finishes so you cannot access it in order to roll back. The code sample above allows you to catch errors that happen during commit and then roll back the transaction that has started already. Now instead of calling the transaction.Commit() in the sample above you call the session.Flush() in my tests no data are saved in the Database as the transaction is never commited.

I have no idea how your code looks like but if you are calling in a pattern, as the above the code sample shows, the transaction.commit() instead of the Session.Flush() it should give you a way to achieve what you want.

Your catch(...) section doesn't add anything functional, as the Dispose() already does a Rollback (if not commited). – taoufik Apr 27 '10 at 11:54 @taoufik I am affraid that your comment is invalid. The Dispose() command of the ITransaction interface as implemented by the AdoTransaction object in the Nbernate code is responsible only for freeing managed and unmanaged resources.

Furthermore a quick look into Nbernate source code proved the fact that the Dispose() does NOT call the ITransaction.RollBack() or the underlying IDbTransaction object's RollBack() method... Therefore the catch(...) section is entirely functional and necessary to the above code sample. – tolism7 Apr 27 '10 at 14:04 The following posting shows a code snippet (from Reflector) which proves that the Dispose does call Rollback: stackoverflow. Com/questions/641660/… – taoufik Apr 27 '10 at 16:03.

Check this: Force query execution without flush/commit I seemed to have the same problem, I would flush and then I would rollback but some data would remain persisted in the database. However, there were some parts in my code that would call a commit, which cannot be rolled back. Consider the accepted answers' code snippet as the proper usage for transactions, flushes, rollbacks and commits and take into consideration that this pattern can be extended... in a single unit of work (ie we consider a Request in a web application as a single unit of work and everything that happens in that request exists in a single transaction which onEndRequest is committed): you call _sessionFactory.OpenSession(), _session.

BeginTransaction(), _session. CommitTransaction() and _session.CloseSession() only once. You can call _session.Flush() and _session.

RollBackTransaction() as many times as you want, but Flush() is automatically called on Commit automatically. You may want to call a Flush when you need to make a query and ensure that the data fetched will not be stale. Note that once a commit transaction is committed, all operations afterwards do not happen on that transaction.

Instead Nbernate will create the necessary transaction under the hood (http://www.nhprof.com/Learn/Alerts/DoNotUseImplicitTransactions) in which point you already have problems tracking consistency and possibly logical integrity If you really must call commit in the middle of your unit of work it is strongly advised to create a new transaction at that point so you can manage it explicitly What's even better is to try out Nested Transactions will allegedly allow partial commits; you can rollback the "root" transaction and all changes will be reverted. I haven't really tested this feature of . NET and SQL Server, although the nested transaction in the database itself leaves a lot to be desired and I don't know how exactly ADO.NET instruments this feature.

Points 1 to 4 have been tested with all versions of Nbernate starting from 1.2.

Thanks for your comment. In your testing did you notice that once data has been flushed it is often not possible to rollback the transaction? This is what is causing me the headache: sometimes you need to flush part way through a transaction, but you also need to be able to roll the transaction back later on.

This doesn't seem to be possible with N – cbp Apr 18 at 8:34 If they have been flushed they are perfectly rollbackable. You have to profile your db operations, maybe something is calling/causing a commit. I've been doing explicit and implicit flushes (when you make an hql/criteria query for example) and doing rollback (on exceptions or for testing) in the end of the transaction with no problems.

– Jaguar Apr 18 at 9:14.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.