Nhibernate.3.0.cookbook the sixth section of the first chapter handling versioning and concurrency translation

Nhibernate.3.0.cookbook the sixth section of the first chapter handling versioning and concurrency translation

Chapter II Mapping a class with XML
Chapter I section III Creating class hierarchy mappings
Chapter Fourth Section mapping a one-to-many relationship
Chapter Fifth section setting up a base entity class

Handling Versioning and concurrency

Version control and concurrency

In any multi-user operating system, in order to handle concurrent updates and version issues, you must choose a processing method in optimistic concurrency control and pessimistic concurrency control. In this section, I'll show you how to use NHibernate to properly handle versions and optimistic concurrency issues

Preparatory work

Complete the tasks in the previous sections, including the section Setting up a base entity class

If you want to do

1. In the entity base class, add a version property with the code as follows:

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>);
}

2. In the product mapping file, add the version element node, name corresponding to the property name, and the code looks like this:

<natural-id mutable= "true" >
<property name= "Name" not-null= "true"/>
</natural-id>
<version name= "version"/>
<property name= "Description"/>
<property name= "UnitPrice" not-null= "true"/>

3. In the Actorrole mapping file, also add the version element node

<id name= "id" >
<generator class= "Guid.comb"/>
</id>
<version name= "version"/>
<property name= "Actor" not-null= "true"/>
<property name= "Role" not-null= "true"/>

Analysis principle

If you have an application that has two users operating the database at the same time, user 1 and User 2 both get the same data to display on their screen, and start modifying the data, User 1 submits his modified data to the database, and in a moment, user 2 submits his modified data. Without any concurrent access checks, User 2 's update will unknowingly overwrite user 1 's update. There are two ways to prevent this from happening: optimistic concurrency control and pessimistic concurrency control.

The process of optimistic concurrency control is this: when the modified data is submitted, first check that the data has been updated. In the above scenario, User 1 and User 2 began to modify their data, User 1 submitted his modified data, when user 2 also submitted the modified data, his update will be unsuccessful, because the data in the database already and user 2 initially obtained the data displayed on the screen is inconsistent.

As shown in the following example, we have a version field that tracks this updated data for an entity, and the update is as follows:

UPDATE Product
SET Version = 2/* @p0 */,
Name = ' Junk '/* @p1 */,
Description = ' Cool '/* @p2 */,
UnitPrice =/* @p3 */
WHERE Id = ' 764de11e-1fd0-491e-8158-9db8015f9be5 '/* @p4 */
and Version = 1/* @p5 */

NHibernate checks if the value of this version is the same as the value when the entity loads data from the database, and then adds 1 to the value, and if the entity has been updated, the value of the version field is not 1, and the UPDATE statement will not update any rows. NHibernate detects that the updated result of the statement returns a 0-row record throws a Stalestateexception exception, meaning that the entity's data is outdated in memory, not up-to-date, and the database is out of sync.

Supplemental knowledge

Another option outside optimistic concurrency control is to use pessimistic locking. The pessimistic locking process is this: When a user acquires data, it adds an exclusive lock to the data, and always adds the exclusive lock when he edits the data, so that when user 1 displays the data on the screen for editing, user 2 can no longer get the same data displayed on the screen. In the above scenario, user 1 obtains the data, and then he has an exclusive lock on the data, and user 2 can no longer read the data from the database. The query for user 2 is blocked until user 1 releases the exclusive lock or the query times out. User 1 When modifying the data, there will inevitably be a phone call or go away to drink a cup of coffee, which will seriously affect the system's concurrent access. In order to achieve the pessimistic lock above, nhibernate requires you to use Session.lock in the application transaction.

Other methods of optimistic concurrency control

In addition to using the version field of the shaping type, NHibernate also allows us to use the Version field based on the datetime type. However, the Micorosoft SQL Server's datetime type has a precision of 3 milliseconds, which can be problematic if the submission of two updates is very close. It is best to use the DateTime2 date type of SQL Server 2008, which has a time precision of up to 100 nanoseconds, or you can use the timestamp date type.

NHibernate also allows you to use traditional optimistic concurrency control in a way that can be implemented by setting the Optimistic-lock property to dirty, a simple example looks like this:

<class name= "Product"
Dynamic-update= "true"
optimistic-lock= "Dirty" >

In this case, the SQL statement that modifies the name of the product object from stuff to junk appears as follows:

UPDATE Product
SET Name = ' Junk '/* @p0 */
WHERE Id = ' 741bd189-78b5-400c-97bd-9db80159ef79 '/* @p1 */
and Name = ' Stuff '/* @p2 */

This ensures that when the user reads the data, the value of name is not updated by another user until the update is committed (other users may have been updated, if it has been updated, the above SQL statement will not update any rows), however, other users may have updated the value of the other fields of the Product object.

Another option is to set the value of Optimistic-lock to all, so that the automatically generated UPDATE statement for the product object will look like this after setting:

UPDATE Product
SET Name = ' Junk '/* @p0 */
WHERE Id = ' d3458d6e-fa28-4dcb-9130-9db8015cc5bb '/* @p1 */
and Name = ' Stuff '/* @p2 */
and Description = ' Cool '/* @p3 */
and UnitPrice = */@p4 */

As you might have guessed, in this case, we need to examine the values of all the attributes, which is not appropriate if there are very many fields.

When you set the value of Optimistic-lock to dirty, the value of dynamic-update must be set to true. Dynamic update means that the UPDATE statement only updates the changed property values, and when Dynamic-update is set to False, update is initialized when the application starts, and it contains the values of all the attributes of the entity.

Nhibernate.3.0.cookbook the sixth section of the first chapter handling versioning and concurrency translation