Answers
Aug 08, 2006 - 01:56 PM
I think I might have found a way to solve the problem.
The issue was that I had some batch operations running every x hours updating some data and it seems that those were causing reads on the same data to be deadlocked.
So now I'm trying to let dirty reads be possible, when I'm doing those updates:
ITransaction tr = session.BeginTransaction(IsolationLevel.ReadUncommitted);
Any save is done within a transaction like this.
The problem is that it's difficult to test thoroughly, since the problems was only ocurring once in a while.
I'll post here again about the result.
The issue was that I had some batch operations running every x hours updating some data and it seems that those were causing reads on the same data to be deadlocked.
So now I'm trying to let dirty reads be possible, when I'm doing those updates:
ITransaction tr = session.BeginTransaction(IsolationLevel.ReadUncommitted);
Any save is done within a transaction like this.
The problem is that it's difficult to test thoroughly, since the problems was only ocurring once in a while.
I'll post here again about the result.
Aug 24, 2006 - 10:40 PM
After testing for a few weeks without getting any problems, I regard the problem as solved.
May 04, 2007 - 02:39 PM
I discovered another issue that might create deadlock problems. It's not related directly to transactions, but to nhibernates handling of dirty objects.
Basically what happened was that i selected a bunch of objects, and looking at the sql trace i saw that they were all immediately updated to the database again. What happens is that if nhibernate detects a "dirty" object, i.e. it has a property that has changed value, it will try to save it to the database per default.
I had a property that i tried to define with my own enum class although it was an integer that was finally saved in the database. well, nhibernate saw that as dirty since the int was not equal to the enum type and therefore saved the object again. this made a huge amount of saves and caused deadlocks simply because the database was overloaded with updates to the same tables and registries.
hope this helps somebody...
Basically what happened was that i selected a bunch of objects, and looking at the sql trace i saw that they were all immediately updated to the database again. What happens is that if nhibernate detects a "dirty" object, i.e. it has a property that has changed value, it will try to save it to the database per default.
I had a property that i tried to define with my own enum class although it was an integer that was finally saved in the database. well, nhibernate saw that as dirty since the int was not equal to the enum type and therefore saved the object again. this made a huge amount of saves and caused deadlocks simply because the database was overloaded with updates to the same tables and registries.
hope this helps somebody...
Jan 25, 2009 - 03:25 AM
In addition to the last point, you always must make sure that the types defined in the class match the types in the database. for example if you have an "int X" then in the DB you mustn't have nullable int or it will be saved inside every transaction you open (nhibernate gets a null from the DB and thinks it's changed because int doesn't accept a null and it has the default value of 0 => 0 != null => dirty)
Add New Comment