Hi, I've stumbled upon a strange problem that I'm not sure is a problem with how I've designed my architecture or with nhibernate. The workaround is easy, but still was wondering how others are handling this scenario.
I'm currently using optimistic locking in nhibernate with the version property. In order to use it I reattach an object using session.Lock. When I update the entity I get the staleObjectException. (BTW, it would be nice to be able to modify the exception string). So far so good.
The problem is when someone clicks on update and the modified values are actually the same. In that case nhibernate will detect that no change was made and thus will not issue an Update command. I understand that performance is the reason behind this behavior, but the problem is that I want to know if I'm modifying an already updated object.
I guess for normal scenarios this is the desired functionality, but having a problem on handling it in ASP.NET. If you're still with me so far let me explain a little more:
For information purposes, I'm using HTTPHandlers to start/stop a nhibernate transaction with each Request/Response
The system has an Entity.Description="BLABLA"
User A opens Entity
User B opens Entity
User A modifies Entity.Description = "A nice description"
User A saves and commits.
User B hits save
Since the properties of Entity.Observation for user B have not changed since the last time he opend the Entity (the Entity is saved in User B HTTP Session), when the server does a reattach using lock it sets the lock using description "BLABLA" and since the information has not changed, nhibernate will no see the new object as dirty since all its properties, even though are set, will be the same. Thus NH will not issue and update and the exception will never be fired.
I can get around this issue by making sure I clear the Description field on each update so that I get the object dirty no matter what, but I believe nhibernate should change this default behavior when optimistic locking is involved.
Thanks!
-Roni Burd
|