How can i force Nhibernate transaction to fail(from the calling code) so i can make sure that the failing behavior is working properly?
I can't modify the source code i just need to make it fail!
example :
public void DoSomething(/*Some parameters*/){
using (var tx = _session.BeginTransaction())
{
try
{
//Do something
tx.Commit();
}
catch (Exception)
{
if (tx != null) tx.Rollback();
throw;
}
} }
Throw an exception.
Throw an exception:
using(var sess = sf.OpenSession())
using(var tx = sess.BeginTransaction())
throw new Exception();
Close the connection:
using(var sess = sf.OpenSession())
using(var tx = sess.BeginTransaction())
sess.Connection.Close();
Rollback the transaction:
using(var sess = sf.OpenSession())
using(var tx = sess.BeginTransaction())
tx.Rollback();
If you have to have the exception occur within the tx.Commit(), then maybe insert/update a record with invalid data (e.g. a string that's too long for the db column).
One idea would be while you're debugging stop at the line immediately before the query execution will be begin and turn off the database then let the code run. However I assume there is a better and more programmatic way to test this.
Set some global variable (I know people had global variables but this is a good use) that the transaction internal code reads and if it sees the variable set throw an exception.
You can write a unit test to verify the expected behaviour of your code.
One way to do it is:
[Test]
public void VerifyExceptionIsThrown()
{
Assert.Throws<NHibernate.HibernateException>(
() =>
{
using (var tx = _session.BeginTransaction())
{
_session.Update(new Entity());
tx.Commit();
}
});
}
An attempt to update a transient entity will throw an exeption.
Alternatively if you use the NHibernateValidator you can explicitly fail a validation you have set, say you entity's Name property should no more than 10 characters long.
If you populate your entity's Name property with a string longer than 10 characters and you try to Save it, the tx.Commit() will throw you an exception.
Related
Quick question.. In a function that checks if a certain Terminal Id is available, is it okay for me to do it as below?
using (var tx = session.BeginTransaction())
{
return ((new TerminalDAO(sm.Session)).Get(tid) == null) ? true : false;
}
Or is it advisable to do it with the Commit()?
Terminal terminal = null;
using (var tx = session.BeginTransaction())
{
terminal = (new TerminalDAO(session)).Get(tid);
tx.Commit();
}
return (terminal == null) ? true : false;
For readonly operations - I would firstly appreciate you, that you did included transaction even for readonly operation - and also suggest to use a rollback and in fact the explicit rollback.
Please check these:
Is it a better practice to explicitly call transaction rollback or let an exception trigger an implicit rollback?
Do I need to call rollback if I never commit?
My reason for explicit Rollback() would be:
Why rollback? We know it is READ, any accidental WRITE is not intended
Why explicit? Anyone coming later can see it. Self-describing code is the way. Relying on defaults could later lead to unexpected behaviour (e.g. vendor changed the defaults)
I have a problem with Session.Clear(), as I understand it this statement should completely reset all changes made in the UOW, the cache etc. The problem is that is does not. My scenario is illustrated in the test below. I add to items, there is a dependency between them I then try to delete the item which the other item is dependent upon. This will cause an exception which is correct. I then clear the session. Finally I try add a new item to the database, when flushing NHibernate will once again try to execute the failing delete statement. Am I misunderstanding the use of Session.Clear()? Or am I missing something else here?
[Fact]
public void Verify_Cant_Clear_Delete()
{
var session = SessionFactory.OpenSession();
var category = new ManufacturerCategory { Name = "category" };
var man = new Manufacturer { Category = category, Name = "man" };
session.Save(category);
session.Save(man);
session.Flush();
try
{
// this will cause
// NHibernate.Exceptions.GenericADOException: could not execute batch command.[SQL: SQL not available]
// ---> System.Data.SqlClient.SqlException: The DELETE statement conflicted with the REFERENCE constraint "ManufacturerCategoryId".
// The conflict occurred in database "LabelMaker-Tests", table "dbo.Manufacturers", column 'Category_id'.
session.Delete(category);
session.Flush();
}
catch (Exception ex)
{
// This should clear the session
session.Clear();
}
try
{
var category2 = new ManufacturerCategory { Name = "category 2" };
session.Save(category2);
session.Flush();
}
catch(Exception ex)
{
// this will cause ONCE AGAIN cause
// NHibernate.Exceptions.GenericADOException: could not execute batch command.[SQL: SQL not available]
// ---> System.Data.SqlClient.SqlException: The DELETE statement conflicted with the REFERENCE constraint "ManufacturerCategoryId".
// The conflict occurred in database "LabelMaker-Tests", table "dbo.Manufacturers", column 'Category_id'.
Assert.True(false);
}
}
You should be using transactions and rollback the transaction on an hibernate exception because...
Certain methods of ISession will not leave the session in a consistent state.
http://nhibernate.info/doc/nh/en/index.html#manipulatingdata-exceptions
or let the transaction be implicitly rolled back via dispose()...
using (ISession sess = factory.OpenSession())
using (ITransaction tx = sess.BeginTransaction())
{
// do some work
...
tx.Commit();
}
I'd guess that the Delete() method is one of the inconsistent state methods hinted at in the above quote...
Your assumptions about ISession.Clear() are not correct.
In particular, as soon as an exception happens, you must discard the session. Clear() will not fix the state (check out 9.8 Exception Handling)
Also, as dotjoe mentioned, you should be using a transaction to do your work.
ok, so Ayende recommends always using a transaction, even for read operations.
but supposing I have the following scenario:
public Employee GetEmployeeByName(string name)
{
using (ITransaction tx = CurrentSession.BeginTransaction())
{
return dao.GetEmployeeByName(name);
}
}
public void SaveNewEmployee(Employee employee)
{
using (ITransaction tx = CurrentSession.BeginTransaction())
{
if (GetEmployeeByName(employee.Name) != null)
{
throw new ArgumentException("employee with same name found");
}
CurrentSession.Save(employee);
}
}
this would actually throw an exception, since nhibernate doesn't support nested transactions.
how can I get around this?
EDIT
this is even a better solution than the one I accepted...
Typically you would get around it by using a unit of work pattern in which you can start your transaction at the same time you open your session. That is to say at the beginning of the unit of work. And you would commit it at the end of the unit of work.
I've just start studying NHibernate 2 days ago, and I'm looking for a CRUD method that I've written based on an tutorial.
My insert method is:
using (ISession session = Contexto.OpenSession())
using (ITransaction transaction = session.BeginTransaction())
{
session.Save(noticia);
transaction.Commit();
session.Close();
}
The complete code of "Contexto" is here: http://codepaste.net/mrnoo5
My question is: Do i really need to use ITransaction transaction = session.BeginTransaction() and transaction.Commit();?
I'm asking this because I've tested run the web app without those two lines, and I've successfully inserted new records.
If possible, can someone explain me too the purpose of Itransaction and the method Commit?
Thanks
This is the proper generic NHibernate usage pattern:
using (ISession session = sessionFactory.OpenSession())
using (ITransaction transaction = session.BeginTransaction())
{
//Do the work here
transaction.Commit();
}
All of that is required to ensure everything works as expected (unless you use additional infrastructure)
Closing the session or doing anything with the transaction besides committing is redundant, as the Dispose methods of the session and the transaction takes care of cleanup, including rollback if there are errors.
It's important to note than doing anything with the session after an exception can result in unexpected behavior, which is another reason to limit explicit exception handling inside the block.
ITransaction transaction = session.BeginTransaction() is not necessary as you found out by testing.
But imagine this, what happens when your session throws an exception? how would you get back your changes to the database?
The following is quote from Nhib...
A typical transaction should use the following idiom:
ISession sess = factory.OpenSession();
ITransaction tx;
try
{
tx = sess.BeginTransaction(); //do some work ...
tx.Commit();
}
catch (Exception e)
{
if (tx != null)
tx.Rollback();
throw;
}
finally
{
sess.Close();
}
If the ISession throws an exception, the transaction must be rolled back
and the session discarded. The internal state of the ISession might not be
consistent with the database after the exception occurs.
NHibernate.ISessionFactory
Well you call Commit() on your transaction it saves all the changes to the database.
Do i really need to use ITransaction transaction = session.BeginTransaction() and transaction.Commit();?
yes it is considered good practice using transactions for everything even simple reads.
tested run the web app without those two lines, and I've successfully inserted new records.
that because the session will commit the changes when it is disposed at the end of the using statement.
anyway this is how i would right the save :
using (ISession session = Contexto.OpenSession())
{
using (ITransaction transaction = session.BeginTransaction())
{
try
{
session.Save(noticia);
transaction.Commit();
}
catch(HibernateException)
{
transaction.Rollback();
throw;
}
}
}
I made a test class against the repository methods shown below:
public void AddFile<TFileType>(TFileType FileToAdd) where TFileType : File
{
try
{
_session.Save(FileToAdd);
_session.Flush();
}
catch (Exception e)
{
if (e.InnerException.Message.Contains("Violation of UNIQUE KEY"))
throw new ArgumentException("Unique Name must be unique");
else
throw e;
}
}
public void RemoveFile(File FileToRemove)
{
_session.Delete(FileToRemove);
_session.Flush();
}
And the test class:
try
{
Data.File crashFile = new Data.File();
crashFile.UniqueName = "NonUniqueFileNameTest";
crashFile.Extension = ".abc";
repo.AddFile(crashFile);
Assert.Fail();
}
catch (Exception e)
{
Assert.IsInstanceOfType(e, typeof(ArgumentException));
}
// Clean up the file
Data.File removeFile = repo.GetFiles().Where(f => f.UniqueName == "NonUniqueFileNameTest").FirstOrDefault();
repo.RemoveFile(removeFile);
The test fails. When I step in to trace the problem, I found out that when I do the _session.flush() right after _session.delete(), it throws the exception, and if I look at the sql it does, it is actually submitting a "INSERT INTO" statement, which is exactly the sql that cause UNIQUE CONSTRAINT error. I tried to encapsulate both in transaction but still same problem happens. Anyone know the reason?
Edit
The other stay the same, only added Evict as suggested
public void AddFile<TFileType>(TFileType FileToAdd) where TFileType : File
{
try
{
_session.Save(FileToAdd);
_session.Flush();
}
catch (Exception e)
{
_session.Evict(FileToAdd);
if (e.InnerException.Message.Contains("Violation of UNIQUE KEY"))
throw new ArgumentException("Unique Name must be unique");
else
throw e;
}
}
No difference to the result.
Call _session.Evict(FileToAdd) in the catch block. Although the save fails, FileToAdd is still a transient object in the session and NH will attempt to persist (insert) it the next time the session is flushed.
NHibernate Manual "Best practices" Chapter 22:
This is more of a necessary practice than a "best" practice. When
an exception occurs, roll back the ITransaction and close the ISession.
If you don't, NHibernate can't guarantee that in-memory state
accurately represents persistent state. As a special case of this,
do not use ISession.Load() to determine if an instance with the given
identifier exists on the database; use Get() or a query instead.