Some of the wording on the NHibernate Session functions can be a tad misleading, or hard to understand. One is â€˜Updateâ€™, Update in many ways should be called â€˜Attachâ€™! So, letâ€™s review what Update does:
This sounds like something you call to â€˜saveâ€™ something right? Actually itâ€™s not. The â€˜saveâ€™ occurs on Save/Commit/Flush. ie.
using var tran = new Transaction
Order order = Session.GetById(â€¦)
order.Updated = true;
Session.Update(order) <— not needed
Update is actually for â€˜trackingâ€™ â€“ not saving. Letâ€™s say you have an object that is detached from a session â€“ by calling Update on that object will tell NHibernate to start tracking the object again.
ie letâ€™s say we get Order from the HttpSessionâ€¦
Order order = Session[â€œOrderâ€] as Order;
So, in summary â€˜Updateâ€™ is for re-associating an object back to the the NHibernate session. Here is the catch as well â€“ it is telling NHibernate that it is expecting it to be â€˜savedâ€™. You can use Lock and define a LockMode to tell NHibernate that a â€˜saveâ€™ might not be required.
In a test simulating a n-tier environment, I did detach (Evict) the object, then call â€˜Updateâ€™ and â€˜Lockâ€™, it was able to save the object. I plan on seeing how to work with optimistic concurrency.
What I find interesting is how badly Linq to Sql appears to handle this vs. NHibernate. This is what Iâ€™m researching at the moment, so if anyone has advice in this area let me know.