XY-ORM tutorial 5: solutions to data concurrency

We always encounter data concurrency in the development project process. Mastering the concurrent data access technology is essential to ensure database correctness and consistency. To solve the concurrency problem, you can start with the database and control the program itself. Now we will discuss how to control the concurrency of the program itself.

The XY-ORM platform provides two solutions: Pessimistic concurrency and optimistic concurrency. Configure different solutions for different applications.

I will not describe the concept of pessimism and optimism in detail here, and there are also a lot of bloggers ..

In the XY-ORM, to realize the control through pessimistic concurrency, it is to enable the transaction through a lock behavior, in the transaction execution process, prevent other users to access or update the record;

The system supports the following lock actions:

// Summary:
// Specify the transaction lock behavior of the connection.
Public enum IsolationLevel
{
// Summary:
// The isolation level is different from the specified isolation level, but cannot be determined.
Unspecified =-1,
//
// Summary:
// The pending changes in the transaction with a higher isolation level cannot be overwritten.
Chaos = 16,
//
// Summary:
// Dirty reads are allowed, meaning that shared locks are not published or exclusive locks are not accepted.
ReadUncommitted = 256,
//
// Summary:
// Keep the shared lock when reading data to avoid dirty reading, but you can change the data before the transaction ends, resulting in non-repeated reading or phantom data.
Readcommitted= 4096,
//
// Summary:
// Place a lock on all data used in the query to prevent other users from updating the data. Prevents repeated reads, but still supports phantom rows.
Repeatableread= 65536,
//
// Summary:
// Place a range lock on System. Data. DataSet to prevent other users from updating rows or inserting rows into the DataSet before the transaction is completed.
Serializable = 1048576,
//
// Summary:
// Reduce blocking by storing the same data version that another application can read when one application is modifying data. Indicates that you cannot see the changes made in other transactions from one transaction, even if you re-query.
Snapshot = 16777216,
}

The method of pessimistic concurrency through XY-ORM is as follows:

// First, create a user-based Data Access Object:
BaseDao <UserInfo> dao = new BaseDao <UserInfo> ();

// Enable the transaction and set the Transaction Level Lock to RepeatableRead to prevent other users from updating data
Dao. GetSUDEoOption (). AutoTransaction = true;
Dao. GetSUDEoOption (). IsolationLevel = System. Data. IsolationLevel. RepeatableRead;

// Load the saved user
UserInfo userLoad = dao. load (string. format ("select {0} from {1} where {2} = '{3}'", dao. entity. columnNames, dao. entity. tableName, "id", user. id ));
// Modify the name and update it to the database
UserLoad. Name = "Li Si ";
Dao. SaveOrUpdate (userLoad );

 

With optimistic concurrency control, it is controlled through SQL statements. Since the XY-ORM in the UPDATE, DELETE entity, the generated update SQL, delete SQL is by ADO.. NET DbCommandBuilder, where constraints for controlling these SQL statements are all achieved through the ConflictOption attribute to our expectations. Let's take a look at the enumerated values of this attribute:

// Summary:
// Specify how to detect and resolve conflicting changes to the data source.
Public enum ConflictOption
{
// Summary:
// The update and delete statements include all searchable columns in the table in the WHERE clause.
CompareAllSearchableValues = 1,
//
// Summary:
// If any Timestamp Column exists in the table, these columns are used in the WHERE clause for all generated update statements.
CompareRowVersion = 2,
//
// Summary:
// All update and delete statements only contain the System. Data. DataTable. PrimaryKey column in The WHERE clause. If System. Data. DataTable. PrimaryKey is not defined, all searchable columns are included in
// In the WHERE clause. This is equivalent to OverwriteChangesUpdate | OverwriteChangesDelete.
OverwriteChanges = 3,
}

The xiangyi platform also encapsulates this attribute in BaseDao. You can set this attribute to achieve the granularity of concurrency.

// First, create a user-based Data Access Object:
BaseDao <UserInfo> dao = new BaseDao <UserInfo> ();

// The where statement only contains the primary key field
Dao. GetSUDEoOption (). OptimismConcurrent = System. Data. ConflictOption. OverwriteChanges;

// The where statement contains the primary key field and any timestamp Field
Dao. GetSUDEoOption (). OptimismConcurrent = System. Data. ConflictOption. CompareRowVersion;

// The where statement contains all fields
Dao. GetSUDEoOption (). OptimismConcurrent = System. Data. ConflictOption. OverwriteChanges;

// Load the saved user
UserInfo userLoad = dao. load (string. format ("select {0} from {1} where {2} = '{3}'", dao. entity. columnNames, dao. entity. tableName, "id", user. id ));
// Modify the name and update it to the database
UserLoad. Name = "Li Si ";
Dao. SaveOrUpdate (userLoad );

// Delete a user
Dao. Delete (userLoad );

 

Therefore, based on the transaction and SQL control concurrency solutions, the xiangyi platform is encapsulated in the data access layer.

Some points may not be quite clear. You can join the discussion group: 222515272. I hope everyone will be awesome!

Xiangyi software, All Rights Reserved