代码改变世界

NHibernate Notes2_Handling versioning and concurrency

2011-09-04 22:47  小郝（Kaibo Hao）  阅读(320)  评论(0)  编辑  收藏  举报

Optimistic concurrency is the process where data is checked for changes before any update is

executed. In this scenario, user #1 and user #2 both begin their changes. User #1 submits her

changes. When user #2 submits his changes, his update will fail because the current data (after

user #1's changes) doesn't match the data that user #2 originally read from the database.Update statements takes the following form:

 

UPDATE Product

SET Version = 2 /* @p0 */,

Name = 'Junk' /* @p1 */,

Description = 'Cool' /* @p2 */,

UnitPrice = 100 /* @p3 */

WHERE Id = '764de11e-1fd0-491e-8158-9db8015f9be5' /* @p4 */

AND Version = 1 /* @p5 */

 

Steps

  1. Setting up a base entity class, adding version property which can be integer version based or DateTime-based version(use SQL Server 2008's DataTime2 data type which has a resolution of 100 nanoseconds or even SQL Server's timestamp data type for the version field, because datetime resolution of about three milliseconds which may fail when two updates occur almost simultaneously).

 

  1. Add version property to Entity base class:

public abstract class Entity<TId>

{

public virtual TId Id { get; protected set; }

protected virtual int Version { get; set; }

public override bool Equals(object obj)

{

return Equals(obj as Entity<TId>);

}

 

  1. Add version property declaration to entity configuration xml

<natural-id mutable="true">

<property name="Name" not-null="true" />

</natural-id>

<version name="Version" />

<property name="Description" />

<property name="UnitPrice" not-null="true" />

 

Pessimistic locking is the process where a user obtains an exclusive lock on the data while they are editing it.  In this scenario, once user #1 pulls up the data,she has an exclusive lock. User #2 will not be able to read that data. To implement this type of locking with NHibernate, your application must call session.Lock within a transaction.

 

Other methods of optimistic concurrency

Traditional form of optimistic concurrency through the mapping attribute optimistic-lock

  • set optimistic-lock to dirty

<class name="Product" dynamic-update="true" optimistic-lock="dirty">

 

UPDATE Product

SET Name = 'Junk' /* @p0 */

WHERE Id = '741bd189-78b5-400c-97bd-9db80159ef79' /* @p1 */

AND Name = 'Stuff' /* @p2 */

 

This ensures that the Name value hasn't been changed by another user because this user

read the value. Another user may have changed other properties of this entity.

 

When optimistic-lock is set to dirty, dynamic-update must be true.

Dynamic update simply means that the update statement only updates dirty properties, or properties

with changed values, instead of explicitly setting all properties.

  •  
    • set optimistic-lock to all

<class name="Product" dynamic-update="true" optimistic-lock="all">

 

UPDATE Product

SET Name = 'Junk' /* @p0 */

WHERE Id = 'd3458d6e-fa28-4dcb-9130-9db8015cc5bb' /* @p1 */

AND Name = 'Stuff' /* @p2 */

AND Description = 'Cool' /* @p3 */

AND UnitPrice = 100 /* @p4 */