tags:

views:

73

answers:

2

For performance reasons, sometimes I want to update entities without any version increment(or version check). With LINQ TO SQL, I just left the version unchanged and it worked fine. Is this behavior possible in NHibernate?

A: 

Some of the modifications are not really important. So I want to make those modifications simply last one win.

While transactions are meant to be atomic, so that we can speak in term of temporal order, it's not simple and it's always a bit tricky to speak of first/last when transactions are involved. E.g.

T1: start
T1: read row X with value A
T2: start
T2: read row X with value A
T2: write row X with value A2
T2: commit
T1: write row X with value A1
T1: commit

While T2 starts after T1, the change A2 is lost. Which transaction is the "last one"? The one that started last, or the one that ended last? (The commit is really atomic, but transactions still have a duration, which make them hard to reason about.)

Optimistic or pessimistic locking is meant to avoid such situation, so that we can better think in term of transaction order.

That said, to come back to your question, if that's really what you want, you could try to map the same database table twice in two entities: in one entity you have @version and in the other not. But that can be rather confusing.

ewernli
A: 

I believe you probably don't want to disable all optimistic locking on these entities (otherwise just don't give them a version property), but you want some properties not to cause the version to increment. That is supported using "optimistic-lock", check: http://nhforge.org/doc/nh/en/index.html#mapping-declaration-property

optimistic-lock (optional - defaults to true): Specifies that updates to this property do or do not require acquisition of the optimistic lock. In other words, determines if a version increment should occur when this property is dirty.

Fried Hoeben