http://www.cnblogs.com/kristain/articles/2038397.html
1. What is business
-
atomicity . That is, indivisible, transactions are either all executed, or none of them are executed. If all sub-transactions of the transaction are successfully submitted, all database operations are submitted and the database state is converted; if any sub-transaction fails, the database operations of other sub-transactions are rolled back, that is, the database returns to the state before the transaction was executed. State transitions do not occur.
-
Consistency or stringability . The execution of a transaction causes the database to transition from one correct state to another.
-
isolation . Any changes to data made by a transaction are not allowed to be made available to any other transaction until the transaction is properly committed, that is, its possible results should not be shown to any other transaction until the transaction is properly committed.
-
Persistence . After a transaction is committed correctly, its results will be permanently stored in the database, even if there are other failures after the transaction is committed, the processing results of the transaction will be preserved.
Running an embedded SQL application or script, the transaction starts automatically the first time an executable SQL statement is executed (after a connection to the database is established or after an existing transaction terminates). After a transaction is started, it must be explicitly terminated by the user or application that started the transaction, unless a process called automatic commit is used (in which case each individual SQL statement issued is considered do a single transaction, it is implicitly committed as soon as it executes).
In most cases, a transaction is terminated by executing a COMMIT or ROLLBACK statement. When a COMMIT statement is executed, all changes made to the database since the transaction started are made permanent -- that is, they are written to disk. When the ROLLBACK statement is executed, all changes made to the database since the transaction started are undone, and the database is returned to the state it was in before the transaction started. In either case, the database is guaranteed to return to a consistent state when the transaction completes.
It is important to note that although transactions provide general database consistency by ensuring that changes to data are made permanent only after the transaction has been successfully committed, it is still up to the user or application to ensure that changes performed in each transaction are A sequence of SQL operations always results in a consistent database.
Second, the database system supports two transaction modes:
- Auto-commit mode: Each SQL statement is an independent transaction. After the database system executes an SQL statement, it will automatically commit the transaction.
- Manual commit mode: Transaction start and end boundaries must be specified explicitly by the database client.
Note: There are three types of database tables in MySQL: INNODB, BDB and MyISAM, among which MyISAM does not support database transactions. The create table statement in MySQL defaults to the MyISAM type.
3. For multiple transactions running at the same time, when these transactions access the same data in the database, if the necessary isolation mechanism is not adopted, it will lead to various concurrency problems. These concurrency problems can be classified into the following categories:
- The first type of lost updates: when a transaction is revoked, the updated data submitted by other transactions is overwritten.
- Dirty read: A transaction reads an update committed by another transaction.
- Dummy read: A transaction reads newly inserted data that has been committed by another transaction.
- Non-repeatable read: A transaction reads updated data that has been committed by another transaction.
- The second type of lost updates: This is a special case of non-repeatable reads, where one transaction overwrites the updated data that has been committed by another transaction.
4. Isolation level
When the database system adopts the read Commited isolation level, it will cause non-repeatable read and the second type of concurrency problem of lost updates. Pessimistic locks or optimistic locks can be used in applications to avoid such problems. From an application perspective, locks can be divided into the following categories:
- Serializable (serialization): A transaction cannot see the updates made to the database by other transactions during execution.
- Repeatable Read: A transaction can see the newly inserted records that have been committed by other transactions during the execution process, but cannot see the updates to existing records by other transactions.
- Read Commited: A transaction can see the newly inserted records that other transactions have committed during the execution process, and can see the updates to existing records that other transactions have committed
- Read Uncomitted (read uncommitted data): A transaction can torture newly inserted records that other transactions have not committed during execution, and can see updates to existing records that other transactions have not committed.
The higher the isolation level, the better the data integrity and consistency can be guaranteed, but the greater the impact on concurrent performance. For most applications, it is preferable to set the isolation level of the database system to Read Commited, which can avoid dirty reads and has better concurrent performance. Although it can cause concurrency problems such as non-repeatable reads, virtual reads, and second-class lost updates, in individual cases where such problems may occur, pessimistic locking or optimistic locking can be used by the application to control.
When the database system adopts the read Commited isolation level, it will cause non-repeatable read and the second type of concurrency problem of lost updates. Pessimistic locks or optimistic locks can be used in applications to avoid such problems. From an application perspective, locks can be divided into the following categories:
A. Pessimistic lock : refers to the lock of data resources displayed in the application. Although it prevents concurrency issues like lost updates and non-repeatable reads, it can affect concurrency performance and should be used with caution. B. Optimistic locking : Optimistic locking assumes that when the current transaction operates a data resource, no other transaction will access the data resource at the same time, so it completely relies on the isolation level of the database to automatically manage the lock work. The application uses version control to avoid possible concurrency problems.
5. There are two ways to implement pessimistic locking.
A. In the application program, it is specified to use the exclusive database system to lock data resources. SQL statement: select ... for update, use get in Hibernate, load such as session.get(Account.class, new Long(1), LockMode, UPGRADE) B. Add a LOCK to the database table to indicate the record status Field, when its value is "Y", it means that the record has been locked by a transaction, if it is "N", it means that the record is in an idle state and the transaction can access it. This can be achieved by adding a lock tag field.
Using Hibernate's Version Control to Implement Optimistic Locking
Optimistic locking is a mechanism provided by the program, which can not only ensure concurrent access to data by multiple transactions, but also prevent the second type of lost update problem.
In the application, the version control function provided by Hibernate can be used to optimistically lock the line of sight. Both the <version> element and <timestamp> in the OR mapping file have the function of version control, and <version> is generally recommended.