Can anyone explain optimistic locking in the context of NHibernate? (Using
NHib 2.1.1.)
I’ve been running tests and my results are counter-intuitive. I have a
versioned entity:
<class name="Test.Entity, Test" table="tblEntity" abstract="false"
optimistic-lock="version">
<id name="Id" column="scheduleId" access="property" unsaved-value="0"
type="Int64">
<generator class="hilo">
<param name="table">tblHiloUId</param>
<param name="column">nextHighValue</param>
<param name="max_lo">100</param>
</generator>
</id>
<version column="version" name="Version" type="Int32"
unsaved-value="0" />
<property name="Prop1" column="prop1" update="false"
access="property" not-null="false" type="Boolean"
optimistic-lock="true" />
<property name="Prop2" column="isDefaultOverridable"
access="field" not-null="true" type="String"
optimistic-lock="true" />
</class>
And the following test:
[Test, ExpectedException(ExceptionType=typeof(StaleObjectStateException))]
public void SavingUpdatesOptimisticLockShouldThrow()
{
var cfg = new NHibernate.Cfg.Configuration();
cfg.AddAssembly("Test");
cfg.Configure();
var sessionFactory = cfg.BuildSessionFactory();
var sess1 = sessionFactory.OpenSession();
var sess2 = sessionFactory.OpenSession();
sess1.BeginTransaction();
sess2.BeginTransaction();
// NOTE: I get the same results if I load with Lock.None
// A record is loaded in the DB in test setup, assigned to m_Id
var a = sess1.Load<Entity>(m_Id);
var b = sess2.Load<Entity>(m_Id);
a.Prop2 = "New test value, session1”;
sess1.Save(a);
sess1.Transaction.Commit();
b = "Another, session2";
sess2.Save(b);
sess2.Transaction.Commit(); // Should throw?
}
After reading the docs, this is what I’d expect to see:
Both instances start with version=1. When I save and commit a, I see that
its version number is incremented from 1 to 2, while b still has version=1
(as I’d expect). I’d expect that the call to sess2.Transaction.Commit()
should throw, because NHibernate will determine that the record was updated
since b was loaded, so optimistic concurrency issue. But it doesn’t – b
commits fine, and overwrites changes saved when a was saved.
If I load explicitly selecting the lock I want, it does work as I’d expect
and I get my exception.
This is surprising to me. Ayende noted in a concurrency blog post
(http://ayende.com/Blog/archive/2009/04/15/nhibernate-mapping-concurrency.as
px) that using a version column should result in the generated UPDATE SQL
statement to compare against the version number – and if the version doesn’t
match the original version, we should get a StaleObjectException.
Can anyone clarify what’s going on here?
Thanks.
Remi.
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=.
