views:

160

answers:

2

I have an entity mapped in NHibernate with optimistic concurrency control using a SQL timestamp column as the version number. The mapping is like the following:

<class name="Entity" optimistic-lock="version" discriminator-value="0">
    <id name="id">
        <generator class="native" />
    </id>
    <version name="Version" column="Version" generated="always" unsaved-value="null" type="System.Byte[], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    ...
    <subclass name="ChildEntity" discriminator-value="1" />
</class>

I am testing what happens when the data in a row in the database changes between the get and the update of the record. To do so, I am running an update statement directly against one of the records in the table that are in the process of being updated by NHibernate. This direct update changes the version number of the record in the table.

As expected, the NHibernate managed update does not occur on the specific row (this is good). However, no exception is thrown during the commit. I expected a StaleObjectStateException to occur when the transaction was committed so that I could roll back the transaction and inform the user. Isn't this the expected behavior? Am I missing something?

My code to commit the transaction looks something like this:

_session.BeginTransaction();
...
// load objects in session
IList<ChildEntity> toChange = _session.Find('some condition');
foreach ( var itemToChange in toChange )
{
     itemToChange.Status = Status.Updated;
}
...
_session.Transaction.Commit();

The items belong to the same session and all work is completed within a single transaction. ChildEntity is a subclass of the Entity base class, which has the optimistic-lock set to version.

+2  A: 

How are you modifying the data? The StaleObjectException is thrown only when NHibernate attempts to update the row and the version number is no longer the same. The other columns are irrelevant. Is it possible that in your testing you are not updating the version number?

The premise is this:

A. User A & B get object from database with version = 1

SQL: SELECT [object] FROM [TABLE] where id = [id] and Version = 1

B. User A Updates object which changes the version to 2

SQL: UPDATE [TABLE] SET [object] (& Set Version = 2) where id = [id] and Version = 1 returns 1 row updated

C. User B attempts to update object but gets StaleObjectException as update object with version = 1 (the version he got it step 1) updates 0 records in the database.

SQL: UPDATE [TABLE] SET [object] where id = [id] and Version = 1 returns 0 rows updated and StaleObjectException thrown.

Michael Gattuso
A: 

It appears that my testing was inaccurate. In the test, I was doing the get AFTER the other transaction updated the record. This other update made the row ineligible for the update, so no update was attempted. When I changed the test to make the competing update AFTER the Get, then the StaleObjectStateException was thrown as expected.

Sorry for the confusion.

SteveBering