I am developing an application using NHibernate 1.2.
For optimistic concurrency, I am using the version property by specifying the following in the xml file.

optimistic-lock="version"
<version name="RowVersion" column="RowVersion"
type="NamespaceName.UserTypeTimestamp, NamespaceName"
generated="always" unsaved-value="null" />

If you are wondering what is UserTypeTimestamp, it is a custom class that is available as part of the sample code at
http://www.codeproject.com/useritems/Op ... xTable.asp

As far as optimistic concurrency is concerned everything works fine. Only issue that I have is that the update statements has SET command for all the columns (changed /unchanged). As I am using multiple sessions, the dynamic-update hasn't worked for me to send only the dirty columns in the update query.

Next approach I took is to set the select-before-update property to true along with the dynamic-update property.

dynamic-update="true"
select-before-update="true"

This had lead to the following:
1. A select is performed for the object id being updated
2. Dirty columns are identified
3. Update query is created with SET command for the dirty columns and the row version.


Due to #3, an exception is thrown. I am trying to understand why the update statement has a SET for the row version even though it is specified as database generated property and the row version value hasn't changed (it is the same as what is in the database). Looks like Select before update has returned the RowVersion as a dirty column for some reason.

I would like both the optimistic concurrency(using version property) and the update statement (with only the dirty fields) to work correctly.

Do anyone have better ideas? Is anything wrong with what I am doing? Is it a limitation with NHibernate?

Appreciate your help. Thanks.

By chance does you entity have an associated Bag with cascading operations? I had the same exact problem when using that UserTypeTimestamp. But it only happened during a delete operation on an entity having a cascading bag.

I have since given up on using SQL server TimeStamps and gone with the NHibernate Timestamp (which is actually a .NET DateTime). This works in all cases (even with the weird extra update). The only problem is that any other application that might be updating your database has to know to update the version field, otherwise you run the very slim chance of overwriting that application's changes with your app. Seems like a good tradeoff to me.

Thanks for your reply.

The entity that I am using doesn't have any cascading.

The intention is the version column should never be updated by any application and it need to be auto generated by the database if the row is updated. I tried using NHibernate timestamp and it hasn't worked for me.

As I mentioned earlier, optimistic concurrency works fine. The issue is using select-before-update along with optimistic concurrency as it creates update query with SET statement for the RowVersion column.
The update query created without using select-before-update doesn't have the SET statement for RowVersion column but has SET for all of the other columns. I am trying restrict it to have the SET for only dirty columns by setting select-before-update property to true.