I am trying to use NHibernate in combination with .NET's TransactionScope object. So far I have successfully used Oracle 11g and SQL Server 2008R2 with no issues. However, SQL Compact seems to fall on its face.
using (var scope = new TransactionScope(TranactionScopeOption.Required))
{
using (var session = _sessionFactory.OpenSession())
{
// The line below throws. I also tried passing in System.Data.IsolationLevel.ReadCommitted to no avail
using (var txn = session.BeginTransaction())
{
// Perform insert
txn.Commit();
}
}
scope.Complete();
}
This results in the following exception. I understand what this means, but I don't understand why it is attempting to create a nested transaction.
NHibernate.TransactionException: Begin failed with SQL exception ---> System.InvalidOperationException: SqlCeConnection does not support nested transactions.
at System.Data.SqlServerCe.SqlCeConnection.BeginTransaction(IsolationLevel isolationLevel)
at System.Data.SqlServerCe.SqlCeConnection.BeginDbTransaction(IsolationLevel isolationLevel)
at System.Data.Common.DbConnection.System.Data.IDbConnection.BeginTransaction(IsolationLevel isolationLevel)
at NHibernate.Transaction.AdoTransaction.Begin(IsolationLevel isolationLevel)
at NHibernate.Transaction.AdoTransaction.Begin(IsolationLevel isolationLevel)
Your code potentially produces 2 transactions:
1)new TransactionScope(TranactionScopeOption.Required)
2)session.BeginTransaction()
TransactionScope.Required "uses an ambient transaction if one already exists. Otherwise, it creates a new transaction before entering the scope. This is the default value". Your are guaranteed to have an ambient transaction by time session.BeginTransaction() gets hit, hence, making it a nested transaction.
If the transaction scope is not completed everything within its scope will be rolled back.
I think the answer lies in this question: The connection object can not be enlisted in transaction scope
"At a guess, TransactionScope needs to escalate to a distributed or nested transaction, neither of which is supported by CE."
Related
I am just getting started using nHibernate, and some behavior is a bit disturbing, which is it seemingly does not throw exceptions when you try to perform some action when you have either coded it oncorrectly, or have a configuration error.
For example, I have some code:
ISessionFactory sessions = SessionManager.SessionFactory;
ISession session = sessions.OpenSession();
ITransaction tx1 = null;
tx1 = session.BeginTransaction();
IList<BusinessUnit> businessUnits = session.QueryOver<BusinessUnit>().List();
System.Diagnostics.Debug.WriteLine("Count: " + businessUnits.Count);
businessUnits[0].Name += "z";
session.Save(businessUnits[0]);
if (tx1 != null) tx1.Commit();
session.Close();
When I first coded it, I did not include the usage of a transaction:
tx1 = session.BeginTransaction();
if (tx1 != null) tx1.Commit();
So, apparently, if a transaction is not present, nHibernate doesn't (at least according to my configuration) automatically create one. Which is fine, I suppose.
But what bothers me is, if a transaction is required, and you try to perform a Save() without one, why doesn't it throw an exception?
(So far I have encountered another similar issue, I tried to load a collection, but apparently some error in my configuration prevented a successful load...so the code executes, but no exception indicating something has gone wrong).
Is there perhaps some config setting I am missing where exceptions are suppressed, or does a person have to unit test everything as no behavior can necessarily be assumed to work?
On a pre-existing object, a Save() is not automatically committed to the database, in the example above, it requires you to call:
Session.flush();
If one uses a transaction, then calling .Commit() on the transaction then invokes a flush().
So the reason no exception is thrown is because caching is default behavior by design (and if the programmer isn't aware of that then they will be very confused!!!)
I have a problem.
using (var tran = repository.Session.BeginTransaction())
{
try
{
repository.Save(entity);
tran.Comit();
}
catch(Exception)
{
tran.Rollback();
throw;
}
}
using (var tran = repository.Session.BeginTransaction())
{
try
{
repository.GetById(id);
tran.Comit();
}
catch(Exception)
{
tran.Rollback();
throw;
}
}
When I try to get an entity by ID after exception and tran.rollback() in the first using block, I get an update exception. So NHibernate is trying to update the entity from the first using block in the second using block.
Why? I did the tran.Rollback(). Must I do Session.Clear(), too?
According to Hibernate's API, when a Hibernate Session throws an exception, you must close the Session and create a new one. Also, when you roll back a Hibernate transaction, you must not later commit it or flush the Session - you must start over in a new Session.
In particular (and this is an implementation detail so don't rely on it), after a rollback, the Hibernate Session still has entities created/modified since the transaction began - Hibernate doesn't go through your entities and revert all changes you made. Therefore, if you roll back the transaction and then flush the Session, Hibernate will commit entity changes that you thought you rolled back. If you are going to play with fire by trying to hack around this behavior (such as by clearing the Session), beware. It's best to just start over with a new Session.
I am trying to use NHibernate with legacy entities that are not mapped with NHibernate. On occasion this means that I need to manually flush NHibernate data to the database so that I don't receive foreign key exceptions when I try to connect the legacy entities with NHibernate-mapped entities.
A problem occurs when this takes place within a transaction that then needs to be rolled back. The data flushed from NHibernate does not rollback.
Is there anything I can do about this?
UPDATE
Still curious how to do this - I don't believe either of the answers given address the issue. I need to call Flush(). The question is, how do I rollback data that has been flushed?
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 NHibernate 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 NHibernate starting from 1.2.
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()) // <-- open scope
try
{
// do something
transaction.Commit();
}
catch (HibernateException)
{
transaction.Rollback();
_session.Close();
_session.Dispose();
throw; // <-- this way the stacktrace stays intact!
}
}
A VB.NET version of this piece of code can be found here.
When using transactions with NHibernate 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 (HibernateException 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 NHibernate mechanisms.
Especially when calling the transaction.Commit() command the AdoTransaction created by NHibernate 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.
I have the following code (simplified for the sake of discussion). What I don't understand is why the session.Transaction property returns a different transaction after a rollback.
For instance, this means that the property Session.Transaction.WasRolledBack is of little help unless I store a reference to the first transaction and check that transaction's property.
Can anybody provide some insight here?
int transId = session.Transaction.GetHashCode();
using (var tx = session.BeginTransaction())
{
Assert.AreEqual(transId, tx.GetHashCode());
tx.Rollback();
Assert.AreEqual(transId, tx.GetHashCode());
Assert.AreEqual(transId, session.Transaction.GetHashCode()); // Fails
}
Update:
David Walschots' answer is very helpful and precise. Also, I found the following in the Nhibernate Documentation:
If you rollback the transaction you should immediately close and discard the current session to ensure that NHibernate's internal state is consistent."
From NHibernate in Action (Kuaté, Harris, Bauer, King):
After committing a transaction, the NHibernate session replaces it
with a new transaction. This means you should keep a reference to the
transaction you're committing if you think you'll need it afterward.
This is necessary if you need to call transaction.WasCommited.
session.Transaction.WasCommitted always returns false.
Most likely the same applies to the Transaction.WasRolledBack property.
From my understanding NServiceBus executes the Handle method of an IMessageHandler within a transaction, if an exception propagates out of this method, then NServiceBus will ensure the message is put back on the message queue (up X amount of times before error queue) etc.. so we have an atomic operation so to speak.
Now when if I inside my NServiceBus Message Handle method I do something like this
using(var trans = session.BeginTransaction())
{
person.Age = 10;
session.Update<Person>(person);
trans.Commit()
}
using(var trans2 = session.BeginTransaction())
{
person.Age = 20;
session.Update<Person>(person);
// throw new ApplicationException("Oh no");
trans2.Commit()
}
What is the effect of this on the transaction scope?
Is trans1 now counted as a nested transaction in terms of its relationship with the Nservicebus transaction even though we have done nothing to marry them up? (if not how would one link onto the transaction of NServiceBus?
Looking at the second block (trans2), if I uncomment the throw statement, will the NServiceBus transaction then rollback trans1 as well? In basic scenarios, say I dump the above into a console app, then trans1 is independent, commit, flushed and won't rollback. I'm trying to clarify what happens now we sit in someone else's transaction like NServiceBus?
The above is just example code, im wouldnt be working directly with session, more like through a uow pattern.
If you mark your endpoint as transaction (.MsmqTransport().IsTransactional(true) or just AsA_Server) then the transactions will enlist into the one NServiceBus opened. What this means is that the commits you have inside your handler won't actually happen and the whole thing will either commit or rollback together - unless you specifically tell your transactions not to enlist in the ambient transaction.
Whether or not you work directly with the session or through a UoW, it looks like you want to do more than one for a given message - why? The message is already the natural UoW.