Castleactiverecord test results record that the database resource competition causes the update to fail when the multi-threaded transaction commits

Castleactiverecord tested, Isolation level:

 

// Abstract:

    //Specifies the transaction locking behavior of the connection.
Public enumIsolationLevel
{
//Summary:
//you are using a different isolation level than the specified isolation level, but this level cannot be determined.
Unspecified =-1,
//
//Summary:
//You cannot overwrite a pending change in a transaction with a higher isolation level.
Chaos = -,
//
//Summary:
//dirty reads can be done, meaning that no shared locks are issued and exclusive locks are not accepted.
readuncommitted = the,
//
//Summary:
//A shared lock is maintained while the data is being read to avoid dirty reads, but the data can be changed before the transaction ends, resulting in non-repeatable reads or phantom data.
ReadCommitted =4096,
//
//Summary:
//locks are placed on all data used in the query to prevent other users from updating the data. Prevents non-repeatable reads, but can still have 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 completes.
Serializable =1048576,
//
//Summary:
//reduce blocking by storing the same version of data that another application can read while one application is modifying data. Indicates that you cannot see changes made in other transactions from one transaction, even if you re-query.
Snapshot =16777216,
}

Unspecified ,Chaos is not supported,Snapshot must modify database support.

In multi-threaded commit, when committing faction, actively suspend the thread 300ms before continuing to commit, with repeatableread mode

Commits can be completed, but there is always no end in mind.

Other modes do not get the correct results in any way, theresult of the readuncommitted pattern is the wrong data, because the transaction process gets dirty data.

Castleactiverecord test results record that the database resource competition causes the update to fail when the multi-threaded transaction commits