The following reason for deadlocks has turned out to be a major issue for 
our application using NHibernate and I am in desperate need for a solution. 

In a multi-threaded/multi-client environment, it appears to be an absolute 
must to ensure that database resources (such as tables, rows, data pages, 
index pages, ...) are locked/acquired in the same order among all 
threads/clients. Any other approach will result in deadlocks. 
Most locks are managed through the database system based on INSERT or 
UPDATE statements. Some systems will be smarter with the resource 
allocation, others are less, but the overall issue remains for all systems.

Explicit locks may be considered to be a solution to some scenarios, but 
their use is very limited. Locks will typically lock data rows or pages, 
but not any index. We have seen deadlocks because a thread did hold a row 
data lock on an entity, but failed to get an index page lock later during 
processing.

*Is there any way to make sure that NHibernate would use a particular order 
of entities for UPDATES and INSERTS?*

The documentation says that upon session commit, the software will always 
do all INSERTS first, then all UPDATES. This appears to be very 
problematic. 

Look at the following scenario: clients/threads receive oder+orderitem 
information which should be added to the database.

   - client 1 receives a new order and therefore creates a new ORDER and 
   one or more ORDERITEMs. It therefore does INSERT ORDER, then INSERT 
   ORDERITEM.
   - client 2 happens to receive a new order item for an existing order and 
   therefore adds a new ORDERITEM to an existing ORDER. The code loads the 
   order, adds an orderitem and updates the order status. Upon flush, 
   NHibernate does INSERT ORDERITEM first, then UDATE ORDER, while the reverse 
   is desirable. 

I have been trying to fiddle around with explicit flush (so update the 
order object, then flush to force the UPDATE, then add the new element). 
This issue is that this gets complicated very quickly. With a medium sized 
domain model, it gets next to impossible. 

I have also considered stateless sessions, where I can determine the order 
myself, but I loose a lot of NHibernate functionality. Not a viable option 
either. 

Any help would be very appreciated!

J.-

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/nhusers/-/Wx-YwK7fMWoJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to