Thank you very much for the feedback. All what you said sounds reasonable 
to me ... but I cannot derive a solution from that, at least yet.

Let me emphasize a number of things:

   - My application does NOT operate on the same data rows concurrently and 
   I am still seeing deadlocks. I was very surprised seeing that the lock 
   method approach did not actually help. The lock call was merely locking the 
   data row. Both threads were able to do that since they operate on different 
   orders. The deadlock occurred on index pages. So even with the update 
   lock in place, the DB was still trying to acquire more locks upon the 
   actual update. Plus, an update lock does not work with inserts, since there 
   is nothing to lock.
   - The reorder-sql-in-the-driver approach looks scary to me. Might be a 
   bottomless pit. 
   - The biggest issue with your suggestion #3 - queuing up the changes and 
   then commit them in a proper order - is that the in-memory objects do not 
   reflect the changes. A method 1 runs on the data and (rather than applying 
   the changes) intended modifications are held in a queue. A follow-up method 
   2 that should further process the data sees outdated values and complicated 
   code would need to be added so it can see the changes, but not hibernate to 
   prevent it from flushing.

I do see some potential overlap with the order of inserts and updates 
depending on foreign keys on the matter. However, the flush strategy that 
NHibernate applies actually looks like a contradiction to this. 
Inserting ORDER and ORDERITEM in a transation inserts ORDER first, then 
ORDERITEM (because of the foreign keys).
However, updating ORDER and inserting ORDERITEM in a transation does the 
insert on ORDERITEM first, somewhat despite the foreign key aspects. 

*Is there anyone who understands why all INSERTs before any UPDATEs upon 
flush is a good idea at all? *To me it currently looks like a substantial 
flaw in NHibernate.

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/-/cbqE7_e-1fkJ.
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