Hi,

I have an object with a collection of child object that contain a Rank property. This property indicates the rank of an object within the collection based on a scoring algorithm.

So, I then have a method that will recalculate the ranking of all the objects in the collection and update the DB. There is a real possibility that this method will be executed by 2 users at the same time on the same parent object and it sounds like I need some form of locking to take place while the updates are occuring.

I am not sure how best to do this using NH and would appreciate some guidance.

Thanks,

Jason

I should also mention that the most likely use case is that a user edits one of the child objects in such a way that its ranking changes within the parent collection, thereby triggering a reshuffle of the entire collection.

Transactions and Versions.
IIRC, in this case, modifying the collection would increment the version of the parent.
This way, the second user get a StaleObjectException, and need to think about what he is doing.

Hi,

Thanks for the pointers. I added a <version> property to the child object and was able to generate a StaleObjectException as predicted.

I guess I could catch this exception and give feedback to the user, but I think that this could potentially be a common occurence and might give a poor user experience.

I was hoping that there was some way to lock the objects in the child collection when they are read from the DB, do the reshuffle, save them and then release the locks. Another user trying to do the same function would then be in a holding pattern until the first transaction has finished.

I guess the real contention is with the Rank property as this needs to be recalculated across all of the objects in the collection when any of the objects changes. Is there a pattern that I can use for this type of use case that would eliminate or minimise the concurrency/locking issue?

Thanks,

Jason

Jason, this is actually what was being referred to above. You can use locks if you want. But now you have to think about what is going to take place. There are a lot of different scenarios that can occur when dealing with concurrency. Think about the case where you issue a lock during update (the default SQL Server (assuming you are using Sql Server) behavior is to create exclusive update locks) and the other connections trying to read those records or other connections trying to write to those records will wait until that operation is complete.

When this happens the other user will be in a holding pattern until that update is complete, but once that update is complete their operation can complete successfully. So picture a case where user1 updates, and then user2 updates basically at the same time. The updates for user1 take place while user2 has his or her operations blocked by the lock user1 created. Once user1 releases the locks the update from user2 runs. This seems to be exactly what you are looking for. The only thing is using the version NHibernate will tell you that the update user2 is trying to perform is being performed on a stale object and is therefore unsafe.

So to me it looks like you are getting the results you desired, just maybe not for the exact reasons you expected.

If you wanted to you could also lock with a higher transaction isolation level at the start when the objects are first loaded preventing another user from even loading those objects until the fist process is done, so then their operation would be in a holding pattern until the read->write makes the full cycle.

These options are available, but they are really more database concepts than NHibernate concepts.

Thanks for the comprehensive response.

After giving this some more thought, I do see how my original idea of locking [at the DB level] would probably create concurrency issues for the application and is not generally the recommended approach to take.

I did expirement briefly with using a Serializable isolation level for the transaction but experienced some deadlocks and so quickly abandonded that idea! I probably could have ironed those out but I have decided that the better approach to take is to use versioning and then let NH tell me when an object is stale as recommended.

Using versioning does keep the user more informed of what is happening rather than making some assumptions that may not provide them with the desired results.

It is probably going to be a case of "suck it and see" with our application as we are not really sure just how often this concurrency issue is going to rear its head. At least we now have protective measures in place with versioning to ensure that data doesn't get lost.

Thanks again.

Jason