A detailed introduction to Java basic transactions

This article mainly introduces the relevant information about the detailed introduction of Java basic transactions. Friends who need it can refer to

java transactions detailed explanation

1 , What is a transaction

A transaction is a sequence of operations to access the database. The database application system completes access to the database through transaction sets. The correct execution of a transaction converts the database from one state to another.

Transactions must comply with the ACID principles established by ISO/IEC. ACID is the abbreviation for atomicity, consistency, isolation and durability. Transactions must comply with the ACID principles established by ISO/IEC. ACID is the abbreviation for atomicity, consistency, isolation and durability.

Atomicity. That is, indivisibility, either all transactions are executed or none are executed. If all sub-transactions of the transaction are submitted successfully, 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 transaction execution, no state transition will occur.

Consistency or stringability. The execution of a transaction converts the database from one correct state to another correct state.
Isolation. Before the transaction is correctly committed, any changes to the data by the transaction are not allowed to be provided to any other transaction, that is, until the transaction is correctly committed, its possible results should not be displayed to any other transaction.

Persistence. After a transaction is submitted correctly, its results will be permanently saved in the database. Even if there are other failures after the transaction is submitted, the processing results of the transaction will be saved.

When you run an embedded SQL application or script, the transaction is automatically started the first time the executable SQL statement is executed (after the connection to the database is established or after the existing transaction is terminated) . After starting a transaction, 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 viewed Doing a single transaction is implicitly committed as soon as it is executed).

In most cases, a transaction is terminated by executing a COMMIT or ROLLBACK statement. When the COMMIT statement is executed, all changes made to the database since the transaction was started become permanent - that is, they are written to disk. When the ROLLBACK statement is executed, all changes made to the database since the transaction was started are undone, and the database is returned to the state it was in before the transaction began. 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 become permanent only after the transaction is successfully committed, the user or application is still required to ensure The sequence of SQL operations performed within each transaction always results in a consistent database.

2. The database system supports two transaction modes:

Auto-commit mode: Each SQL statement is an independent transaction. After the database system executes a SQL statement, it will automatically submit the transaction.
Manual commit mode: The specified transaction start boundary and end boundary must be displayed by the database client program.

Note: Database tables in MySQL are divided into 3 types: 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, various concurrency problems will occur. These concurrency problems can be summarized as follows Several categories:

• The first type of lossUpdate: When a transaction is revoked, the updated data submitted by other transactions is overwritten.

• Dirty read: One transaction reads updated data submitted by another transaction.

• Virtual read: One transaction reads newly inserted data that has been submitted by another transaction.

• Non-repeatable read: One transaction reads updated data that has been submitted by another transaction.

• The second type of lost update: This is a special case of non-repeatable read, where one transaction overwrites the updated data submitted by another transaction.
  

4. Isolation level

When the database system adopts the read Commited isolation level, it will lead to the second type of non-repeatable read The concurrency problem of lost updates can be avoided by using pessimistic locking or optimistic locking in the application. From an application perspective, locks can be divided into the following categories:

1. Serializable: A transaction cannot see the updates made to the database by other transactions during execution.

2. Repeatable Read (repeatable read): During the execution of a transaction, you can see the newly inserted records that have been submitted by other transactions, but you cannot see the changes to existing records by other transactions. renew.

3. Read Committed (read committed data): During the execution of a transaction, you can see the newly inserted records that have been committed by other transactions, and you can also see the pairs that have been committed by other transactions. Update of existing records

4. Read Uncomitted (read uncommitted data): During execution, a transaction can copy newly inserted records that have not been committed by other transactions, and can see other transactions There are no committed updates to existing records.

The higher the isolation level, the more complete and consistent the data can be guaranteed, but the greater the impact on concurrency performance. For most applications, you can give priority to setting the isolation level of the database system to Read Commited, which can avoid dirty reads and has better concurrency performance. Although it will lead to concurrency problems such as non-repeatable reads, virtual reads, and second-type lost updates, in individual situations where such problems may occur, they can be controlled by the application using pessimistic locks or optimistic locks.

When the database system adopts the read Commited isolation level, it will lead to non-repeatable reads and the second type of lost update concurrency problems. You can use pessimistic locks or optimistic locks in the application to avoid such problems. From the perspective of the application, locks can be divided into the following categories:

　A. Pessimistic lock: refers to the locking of data resources displayed in the application. Although it prevents concurrency problems such as lost updates and non-repeatable reads, it affects concurrency performance and should be used with caution.

　B. Optimistic locking: Optimistic locking assumes that when the current transaction operates the data resource, no other transactions will access the data resource at the same time, so it completely relies on the isolation of the database levels to automatically manage locks. Applications use version control to avoid possible concurrency issues.

5. There are two ways to implement pessimistic locking.

A. Explicitly specify in the application program to use the exclusive location of the database system to lock data resources. SQL statement: select... for update, use get in hibernate, load like session.get(Account .class,new Long(1),LockMode,UPGRADE)

　B. Add a LOCK field indicating the record status in the database table. When its value is "Y", Indicates that the record has been locked by a transaction. If it is "N", it indicates that the record is idle 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. This mechanism can not only ensure that multiple transactions access data concurrently, but also prevent the second Class missing update problem.

In the application, you can use the version control function provided by Hibernate to view optimistic locking. The element and <timestamp> in the OR mapping file are both version controlled. function, it is generally recommended to use

The above is the detailed content of A detailed introduction to Java basic transactions. For more information, please follow other related articles on the PHP Chinese website!