Transaction (Business Transaction/system transaction) concurrency Policy Selection

 

Optimistic lock:

 

Optimistic lock example http://xmuzyq.javaeye.com/blog/295639
Method 1. JDBC uses the following statement:
Select a. version... from account as a where (where condition ..)
Update account set version = version + 1... (another field) Where version = ?... (Another contidition)

 

Method 2. hibernate:
Public class account {
Long ID;
.......
@ Version // you can also use an XML file for configuration.
Int version
.......
}
In hibernate, a corresponding SQL statement is generated to add the version field 1 and check the corresponding version. If an Optimistic Locking exception is detected, a staleobjectstateexception is thrown.

Compared with optimistic offline locks, optimistic locks are quite understandable. Both optimistic locks and pessimistic locks are within the scope of a system transaction and do not span n system transactions as offline locks. The implementation also utilizes the original sentence 1. Optimistic locks can save checkconcurrent. Saves the first request and puts Verson into the http session.

Comparison 1:
JDBC uses the version field, and hibernate uses the @ version annotation.
Hibernate's @ version is to hand over the work that the application needs to do manually when JDBC is used to the Framework automation. For example, in a JDBC transaction, the value of the version field (version = version + 1 where version =?) needs to be manually updated when an update SQL statement that involves concurrent modifications is involved ?), Then, determine whether the number of rows affected by update is 1. if the value is not 1, it indicates that another transaction modified the record during the modification, at this time, the application manually throws a custom Optimistic Locking exception (or the exception system encapsulated by spring can also be used), while hibernate reduces human efforts to do such a thing. It automatically generates update SQL statements with version updates.

Comparison 2:
The data source of version is a record in dB. For objects in the memory, use the lock assignment or CAS. The version is similar to that of CAS. Generally, CAs can be placed in a while loop. When compare = false, a value is synchronized from the memory and CAS is performed again, the value is successfully assigned until no other threads are modified before the value is assigned to the thread. Java_example. For version, you can also capture and re-execute the update operation until the number of updated rows returned by update is 1 (that is, an exception is thrown when the update is not submitted and the update has been modified ).

 

 

Pessimistic lock: Locks the query record set for access within a single system transaction. The lock will not be released until the update is complete. Once locked, if other system transactions want to operate some records in the record set, they can only wait for the system transaction to release and lock. The implementation uses the implementation provided by DB.
Pessimistic locks are much simpler than pessimistic offline locks. Pessimistic offline locks span multiple system transactions and require applications to control the release and acquisition of locks.

Relationship between pessimistic locks and transaction isolation levels:
1. pessimistic locks can enhance the isolation level of transactions. For example, the transaction itself is a low-level read committed or lower, but when the transaction uses a pessimistic lock, it is equivalent to an increase after its foundation. To the level of Repeatable read.
Parameter http://xmuzyq.javaeye.com/blog/295639
This is easy to understand, because after the first query, the transaction will apply an exclusive lock to [[Selected rows]. Note that the entire table is not locked. In this way, new insert and delete unselected records are allowed. This is the reason why phantom read occurs. It also means that the pessimistic lock cannot be increased to avoid phantom read. If phantom read can be avoided, is added to the serialization level.

2. How to avoid phantom reading problems
To avoid this, we need to set the database isolation level to serializable. In general, because of scalability, the Read committed or lower isolation level is adopted, and concurrency control is implemented with optimistic or pessimistic locks. Therefore, the phantom read problem cannot be avoided while considering the performance. Fortunately, the phantom reading problem is generally not serious.

Principles of implementing pessimistic locks in DB:
1. When Select... where... for update is used, can the insert operation be performed at the same time? I tried it.
2. Use Select... where... for update. You can continue to use Select... where... for update only after executing commit? If there are two: Select... where... for update at the same time, there must be only one execution. After commit, can the other be executed? I tried it.
The rule is: The for update statement locks the tuples in the query results. These tuples cannot be updated, deleted, or for update by other transactions until the transaction is committed.
So
1. Yes, because for update does not lock the entire table, but only locks the select row.
2. Yes

 

Comparison 1: Selection of optimistic locks and pessimistic locks-cost
The cost of re-execution of the business is compared with the cost of pessimistic locking (the thread switching cost caused by synchronized in Java applications, and the cost of using pessimistic locks in database transactions. If the former is greater than the latter, the pessimistic lock should be selected. If the former is smaller than the latter, the optimistic lock should be used. This is the same as optimistic offline and pessimistic offline. The choice of pessimistic lock and optimistic lock is the same as the cost of locking or CAS. The choice of locking or CAS depends on the cost of thread switching and the cost of service execution, such as the design of a counter, using synchronized will lead to thread switching costs higher than simple business success (accumulation ). The Optimistic Locking method of CAS reduces the thread switching cost.
Comparison 2: Pessimistic locks target database records and synchronized targets memory objects, which are very similar.

 

Pessimistic lock example: http://xmuzyq.javaeye.com/blog/295639
1. Use the pessimistic lock in JDBC:
In each conflicting transaction, we must use the select for update statement to access the database. If some transactions do not use the select for update statement, it will easily cause errors, this is also the disadvantage of adopting JDBC for pessimistic control.
If there is an account class in our system, we can do it in the following way:
Select * from account where... (where condition)... for update.

2. Use pessimistic locks in hibernate:
It is much easier to use pessimistic locks in hibernate, because hibernate has APIs for us to call, so as to avoid writing SQL statements directly.
First, we need to clarify the two modes that support pessimistic lockmode. Upgrade and lockmode. upgrade_no_wait in hibernate. (PS: in JPA, the corresponding lock mode is lockmodetype. Read.
If our system has an account class, the specific operations can be as follows:
......
Session. Lock (account, lockmode. Upgrade );
......
Alternatively, you can use the following method to load objects:
Session. Get (account. Class, identity, lockmode. Upgrade ).
In this way, when an object is loaded, Hibernate generates a select for update statement to load the object, locking the corresponding record and avoiding concurrent updates to other transactions.

 

 

Optimistic offline lock:Each record has a version object (the table has a version column, or if the version information is large, such as a calculator, it can be extracted into a version table separately. It has an association with the recorded table .). After the object is read for the first time, the version number is put into the http session. For the second modification request, the first version number retrieved by the session is compared with the version number reread from the database. if the version number is the same, the update operation is performed.

 

Understanding: update the version number in the last update Statement of checkconcurrent and system transaction
Take the business transaction of the two most simplified requests as an example: the system transaction of the first request saves the version number to the HTTP session. Assume that the user has considered n seconds before sending the second request. Sends the second update request.
First understanding:
The second request corresponds to the checkconcurrent in the system transaction, and thinks that the checkconcurrent and the update SQL are in the same system transaction, the update SQL will be successful. Therefore, it is considered that version = version + 1 in SQL updates is only used to record version numbers, and has no other effect-this is the biggest misunderstanding of SQL statements with version updates.
Update comprehension:
In this scenario, shared data may be modified in two time periods. The first time period is between two requests. The second time period occurs in the execution of the system transaction of the update request, provided that the transaction isolation level is lower than the Repeatable read.
Therefore, checkconcurrent and SQL version = version + 1 are just like double insurance. Checkconcurrent can be understood as the first insurance, just as there is a parameter validation at the beginning of the method, the first time to determine whether there are other business transactions in the first time period of the system transaction modified the shared data. Then determine whether there is any value for subsequent execution. Version update can be considered as the second insurance. During the second period, if the isolation level of the transaction is lower than the Repeatable read, other transactions may modify the shared data, in this way, the SQL statement with version updates can perform the final check.

Martin's original statement 1: The optimistic offline lock is usually implemented by adding the version number check in the update or delete statement.
Martin's original statement 2: The version comparison process can be understood as obtaining the lock. Martin also said that if there is no checkconcurrent, if the SQL statement of the original statement 1 can be successfully executed, it can also be understood as [[obtaining locks and executing SQL].
I think poeaa is sometimes confused by these two get locks. Later, the version number is not called get locks, but checkconcurrent. it is used to intercept and determine before executing an update SQL statement to eliminate the possibility of concurrent modifications in advance. 1 is the core principle of optimistic offline locks. Optimistic offline locks can be fully implemented by using 1.

Optimistic offline locks can prevent concurrent modifications, but may not prevent inconsistent reads: Martin says concurrency will lead to two problems: one is concurrent modifications, and the other is inconsistent reads. For more information about inconsistent concepts, see poeaa 5.5.3. For scenarios where optimistic offline locks produce inconsistent reads, the read user address is used to calculate the tax rate when a new bill is created.
Optimistic offline lock solutions for inconsistent reads:
One is to repeat the version number. Similar to the first insurance method, the isolation level of transactions must be repeatable. The Repeatable read level prevents other users from modifying their own Addresses During the transaction execution process. This ensures that the user address read in the transaction of the user who calculates the bill is constant, the data before the address is modified.
The other method is similar to the Method for Solving concurrent updates. You can perform incremental operations on the version number. However, this undoubtedly increases the complexity, because the single-user just wants to read the user's address correctly, and has to make changes to the address update to help judge the inconsistent read.
Gyb: I think it is better to set the isolation level of the transaction to be read repeatedly and re-read the version number to check the address information. Although repeated reads may affect some performance.

The implicit lock is similar to abstracting the operation statement of the original sentence 1 from the application layer to the generic Dao. Avoid application-layer developers forgetting to add SQL statements (version = version + 1 where versoni = ?) Operation.

This optimistic offline lock is compared in the application. Note: checkconcurrent and update operations must be consistent in a system transaction. If you bind the version check directly to the update or delete statement, this problem does not occur.

 

Optimistic offline lock example:
1.
In Martin's optimistic offline lock example, there is no system to implement an optimistic offline lock in a business transaction. For example, if the version status is not saved through HTTP sessoin, there is no first insurance. The example focuses on how to use original statement 1 to avoid concurrent modification. The results of all update statements are used to determine whether the lock is successfully obtained (because it is the second insurance, the lock is successfully obtained and the SQL statement is executed. It seems that the previous "get lock" + "get lock" in the update SQL statement should be renamed, for example, checkconcurrent is more appropriate. Because the "get lock" does not necessarily make the SQL update successful, but it can block it in advance ). In addition, it is expected that the SQL statements with version updates will be constructed at the application layer to be extracted to the super-type layer (for example, we will talk about generic Dao ). Avoid that developers at the application layer forget to construct SQL statements with version updates, and the following persistent layer should do the same. This is also an implicit lock concept. The lock is transparent to application developers.

2.
Merge (version comparison) + update SQL into a system transaction (in fact, the checkconcurrent mentioned above can be used, as long as the update SQL contains version = version + 1 where versoni = ?, With checkconcurrent, You can intercept concurrent modifications in advance ). Another method is to use session. Update (detach object) If Hibernate is used in the persistence layer. The underlying implementation principle should be of the same type as the original sentence 1.

 

 

Q: If a business transaction contains multiple system transactions and multiple update operations, after the last modification transaction fails to be committed, how can I roll back a successfully committed system transaction?
Initially, I thought there should be no such business transaction. Each business transaction should be a N-1 query + 1 update. Therefore, the previous situation solves multiple business transactions.

Final understanding: by reading the hibernate document, we found that if the previous transaction contains modifications, we can set the flushmode = never of the session to avoid flush the changes to the database during commit, in the last system transaction, manual flush is used to refresh all previous updates to the database at a time, and then commit the system transaction.

 

 

Pessimistic offline lock
Pessimistic offline lock: Three lock types available for shared Record Sets
1. Exclusive write lock
The exclusive write lock ignores the reading of data, so it is not guaranteed to read the latest data. It eliminates conflicts when two business transactions modify a copy of shared data at the same time. The applicable scenario is that there is a concurrency modification conflict, but the system does not have a high requirement on the read. For example, if the allowed read is not the latest value, you can consider using an exclusive write lock.
2. Exclusive read lock
The exclusive read lock is only used to read the latest data. Obviously, this lock will limit the concurrency of the system. After all, the system reads far more data than the write, and sacrifices the performance to read new data.
The performance of an exclusive write lock is stronger than that of an exclusive read lock.
3. Read and Write locks that combine the two features above: the Read and Write locks are mutually exclusive. Read locks can be held concurrently.

 

After the lock is defined, the lock management object can be defined. Its attributes include private locks and a data structure holding locks, this data structure can correspond to a memory hash or a database table. The application layer can only operate locks through lock management objects, but cannot directly access locks.

This data structure can be understood as the key-value structure, for example, {business transaction 1 -- lock 1 ,....... business transaction n -- lock n}, business transaction n + 1 must use lock 1, it must wait until lock 1 is released by business transaction 1.
Because it is not convenient to pass the business transaction as a parameter to the lock manager, the concept is stolen because the session can be equivalent to the business transaction. Therefore, the user's sessionid can be used as the key.

Example parameter poeaa

Coarse-granularity lock: if a customer is related to a set of address information. If a business transaction modifies any of these addresses, the whole group of addresses must be locked. (I understand that it is very troublesome to add a lock to each address object to avoid other business objects having to modify another different address and commit to overwrite each other, set the version value to versoin of each address. In this way, the user is locked to its address set.

The fifth chapter of poeaa mentions some concepts about transactions and concurrency policies:

Offline: Many system interactions are not completed in a database transaction. This leads to the issue of managing concurrency in cross-transaction processing. This problem is called offline concurrency (offline concurrency)
The most typical scenario of concurrent modification is SCM. What are the concurrent modification scenarios in enterprise applications? Multiple users have the same permissions. These permissions operate on a file or a database table.

A transaction can be the execution unit of N statements. A transaction must have a clear definition of the start and end commands. The best way to execute a transaction is to request a transaction.

Business transactions do not mean that they cannot be executed in a long system transaction, but only meet the availability and scalability requirements.

Deep understanding of acid in transactions
A: automicity
C: Consistency
I: Isolation
D: Durability

Acid (poaee) of system transactions)

Acid of business transactions (less contact)
The easiest thing to do is ad. A is because when you click the Save button and want to submit all of its modifications, the business transaction starts a system transaction first. System transactions ensure that the modified data is committed as a unit and will be persisted. The only concern is that a correct modification set is maintained during the lifecycle of a business transaction. Therefore, ad can ensure that.
I is the most difficult to guarantee for business transactions, because there is no isolation, resulting in no consistency. The consistency requirement is not to place the record set in an invalid state. However, in the cycle of a business transaction, the shared record set is modified by other business transactions, resulting in invalid record set.

We should try our best to let the transaction system handle the concurrency problem on its own. The cross-system transaction concurrency will let you fall into the Black Water of your own processing concurrency, which is full of aggressive animals. Only when the last resort is required can the business transaction be divided into multiple system transactions. If the business transaction can be completed in a single system transaction, this will be done. If you can tolerate the scalability problems caused by long transactions, do this. You can avoid a lot of trouble by handing over concurrent transactions to the transaction software (mainly the database.

The limitation of optimistic offline locks is that when data is committed, the business transaction will fail, and the cost of failure may be high. For example, a user spends an hour inputting a lease, causing the submission to fail. (Inspiration: when using optimistic offline locks, if the user is required to input too much content. You can ask the user to save the content before submitting, so that after the submission fails, copy and submit again ). The advantage is that it provides the best flexibility.
If the data submission fails, the pessimistic offline lock is considered. It has the advantage that the data has been modified at the earliest time. Otherwise, during the lifecycle of the business transaction, other business transactions cannot modify the shared record set until it is committed successfully. Its disadvantage is that it is difficult to implement and reduces the flexibility of the system.

 

In addition to the business transaction concurrency, there is also another kind of application server concurrency: Different from the application transaction concurrency, there is no access to the shared data source through system transactions. It is a concurrent update of the status in the memory object.
From the request/process with the best isolation to the request/thread with the best performance to the creation of a new business object for each request as much as possible. Without sharing business objects. Similar to the scheme in struts2.

 

 

 

Note: The above notes are mainly taken from poeaa and http://xmuzyq.javaeye.com/blog/295639.