I've ported it to NHibernate 1.2 alpha.

Background: When you’ve set optimistic-lock=”dirty” at the class level in your mapping file, optimistic UPDATE statements are generated, including old values in the WHERE clause. Problem is, there is no way to exclude BLOB / CLOB fields, so the UPDATE fails.

Hibernate 3.0 includes a new property level attribute in the hbm.xml file, where one can specify optimistic-lock=”false” on those properties you wish to exclude from the WHERE clause of the UPDATE.

Cheers,

Stu

optimistic-lock="dirty" should definitely NOT be the default. For some entities you might be able to accept concurrent modifications, for most you don't. With optimistic-lock="dirty" one user could change the price of an item, while the other changes the description, and there would be no conflict detected. This is certainly wrong from a business perspective.

That was copied from my internal email, and I meant to edit out that part :) - it is the default for our system, as we use the 'old values' for conflict resolution.

Edited original post.


BTW: Logged the patch in Jira: http://jira.nhibernate.org/browse/NH-713
Cheers,

Stu

Actually, what is wrong with that, for your very specific scenario, I would argue it's okay. The two pieces of data are not 'related'.

Another example:

I log into some system and update my email, as it changed. At the same time another user updates my customer status, as they were reviewing my record and saw I'd purchased enough product to be elevated. Again, two unrelated pieces of data, so why should a conflict occur? It increases concurrency.

Cheers,

Stu

Of course the price of an item is related to the description. Really, take a step back and consider why person A changes the price: because they think that the new price matches the description. There is a logical dependency between the two values, from a business perspective. This is almost always the case in any business entity. You don't want to make a decision (to modify something) if part of what you are looking at is already outdated.

I'd be very careful before I'd enable optimistic-lock="dirty".

Different perspective: For you its all about concurrency control and conflict resolution in an optimistic scenario. For your application users its really about not wanting to work with stale data (making decisions based on stale data) and needing notification if there is even a minor chance that they made a decision based on stale data. After all, you already took away the pessimistic locking (nobody else can touch this while I look at it) they love so much.

I would argue that you shouldn't be changing the description of a product to a new description when it changes the product's identity. What about all that historical data?

I am not disagreeing that there are reasons for both, however I've do have real world experience with using an optimistic concurrency strategy in business applications, that have been running successfully with 100's and even above 1,000 concurrent users.

Cheers,

Stu

Alright, I guess it was clear what I wanted to say. It should also be clear that my choice of "description" and "price" was illustrative. Pick any two attributes that are interconnected by some external semantics you don't control in your software and you have a problem if you enable optimistic-lock="dirty". Has nothing to do with "identity".

No worries - not trying to pick an argument. I was very interested to hear your thoughts.

Cheers,

Stu