Hey guys,

I currently have a problem with a web app: Obviously a web app is by nature multi-threaded. So what happens is, let's say during request #1 object A gets loaded. Shortly after, request #2 comes in and loads the same object A'. Then request A changes property B from 1 to 2, and request A' changes property C from 1 to 2.

Of course when both transactions commit, one of the updated values gets lost. I started reading into concurrency, versioning, etc. but in the meantime I was wondering if anybody had a simple solution to that problem or a link to a document that explains the possibilities.

Thanks a lot, Christoph

Alright, so I figured that I'll need <version> or <timestamp> in order to allow NHibernate to detect updates in the underlying data storage in the first place.

From what I know, there is no way for NHibernate to work with the SQL timestamp datatype. Is that correct?

So the remaining question then is, I'd like to do a merge between the updates e.g. first done by request/transaction A' with the changes that request/transaction A wants to commit. Obviously they updated different columns in the database.

What would be the most systematic approach to this merge? From my understanding, such an automatic merge would require three copies of the "same" object. The original one before any changes were made, the one that was saved in the meantime (by A') and the "working object" that A modified.

This is fairly unpractical so I'm rather thinking of applying some business logic to the merge since in my particular case A' just sets a flag (short operation) whereas A is a typically longer-running request.

Well anyway, if anybody has some input of recommendations on that, I'd appreciate it a lot.

Thanks, Christoph

Sometimes it helps to keep trying and trying and...

On this one here NHibernate totally blew my mind. By specifying the

DynamicUpdate = true
OptimisticLock = OptimisticLockMode.Dirty

attributes (I'm using NHibernate.Mapping.Attributes) I got NH exactly what I wanted it to do. It's only updating the columns that have truly changed. I checked the SQL commands using Profiler and there are no additional queries, which means NH must keep a copies of retrieved objects with their original state in memory.

While this must come with a slight performance and memory hit, I'll happily take for now.

If anybody has additional input on that, please post.

Thanks, Christoph