The concept of Java transactions

First, what is a business

A transaction is a sequence of operations that accesses a database, and the database application system accesses the database through a transaction set. 　　The proper execution of a transaction causes the database to transition from one state to another state. Transactions must be subject to the ACID principles established by ISO/IEC. Acid is an abbreviated transaction of atomicity (atomicity), consistency (consistency), isolation (isolation), and persistence (durability) that must be subject to the acid principle established by ISO/IEC. Acid is an abbreviation for atomicity (atomicity), consistency (consistency), isolation (isolation), and persistence (durability).

• Atomic Nature . That is, the transaction is either fully executed or not executed at all. If all the child transactions of a transaction are committed successfully, all database operations are committed, the database state is transformed, and if there is a child transaction failure, the database operations of the other child transactions are rolled back, that is, the database returns to the state before the transaction execution, and no state transitions occur.

• consistency or can be strung . The execution of a transaction causes the database to transition from a correct state to another correct state.

• isolation . Before a transaction is properly committed, it is not allowed to make any changes to the data to any other transaction, that is, before the transaction is committed correctly, its possible results should not be displayed to any other transaction.

• Durability . After the transaction is committed correctly, the result is persisted in the database, and the transaction results are saved even if there are other failures after the transaction commits.

Run an Embedded SQL application or script that starts automatically when the executable SQL statement is first executed (after establishing a connection to the database or after the existing transaction terminates). After a transaction is started, it must be explicitly terminated by the user or application initiating the transaction, unless a procedure called autocommit (Automatic commit) is used (in which case each individual SQL statement is treated as a single transaction, it is implicitly committed when executed).

In most cases, the 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 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 revoked, 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 is complete.

It is important to note that although a transaction is permanent only after the transaction has been successfully committed and provides general database consistency, a user or application is required to ensure that the sequence of SQL operations executed in each transaction always results in a consistent database.

Second, the database system supports two kinds of transaction modes:

• autocommit mode: Each SQL statement is a separate transaction, and the transaction is committed automatically when the database system finishes executing an SQL statement.

• Manual Commit mode: the specified transaction start and end boundaries must be displayed by the database client program.

Note: There are 3 types of database tables in MySQL: INNODB, BDB, and MyISAM, where MyISAM does not support database transactions. The CREATE TABLE statement in MySQL defaults to the MyISAM type.

　　

Third, for multiple transactions running concurrently, when these transactions access the same data in the database, if the necessary isolation mechanism is not taken, it will lead to various concurrency problems, which can be summed up in the following categories:

• first category missing updates: When you revoke a transaction, overwrite the updated data that was committed by the other transaction.
• dirty reads: one transaction is read to another transaction for the submitted update data.
• Virtual read: One transaction reads the newly inserted data to another transaction that has been committed.
• non-repeatable READ: One transaction reads the updated data that has been committed by another transaction.
• type two missing updates: This is a special case in non-repeatable reads, where one transaction overwrites the updated data submitted by another transaction.

　

Iv. Isolation Level

When the database system uses the Read Commited isolation level, it causes non-repeatable reads to drink the concurrency problem of the second category of missing updates, which can be avoided by pessimistic or optimistic locking in the application. From an application perspective, locks can be categorized into the following categories:

• Serializable (serialization): One transaction does not fully see the updates made to the database by other transactions during execution.
• REPEATABLE READ (Repeatable Read): a transaction can see newly inserted records that other transactions have committed during execution, but cannot see updates to existing records from other transactions.
• Read commited (reading committed data): a transaction can see the newly inserted records that other transactions have committed during execution, and can see updates to existing records that have been committed by other transactions
• Read uncomitted (reading uncommitted data): a transaction can torture a newly inserted record that is not committed by another transaction during execution, and can see updates to existing records that are not committed by other transactions.

The higher the isolation level, the greater the integrity and consistency of the data, but also the greater the impact on concurrency performance. For most applications, it is preferable to set the isolation level of the database system to read commited, which avoids dirty reads and has good concurrency performance. Although it causes concurrency problems such as non-repeatable reads, virtual reads, and second-class loss updates, the application can be controlled by pessimistic or optimistic locks on individual occasions where such problems may occur.

When the database system uses the Read Commited isolation level, it causes non-repeatable reads to drink the concurrency problem of the second category of missing updates, which can be avoided by pessimistic or optimistic locking in the application. From an application perspective, locks can be categorized into the following categories:

　　A. Pessimistic lock : refers to the data resource lock that is displayed in the application. While it is possible to prevent concurrency problems such as missing updates and non-repeatable reads, it can affect concurrency performance and should therefore be used with caution.

　　B. Optimistic lock : Optimistic locking assumes that the current transaction operations data resource does not return other transactions to access the data resource at the same time, so it relies entirely on the isolation level of the database to automatically manage the work of the lock. The application uses version control to avoid possible concurrency problems.

There are two ways to realize pessimistic locking.

A. The display in the application specifies that the data resource is locked by the exclusive use of the database system. SQL statement: Select ... for update, when using Get,load in hibernate such as Session.get (Account.class,new Long (1), Lockmode,upgrade)

B. Add a lock field in the database table indicating the status of the record, when it has a value of "Y", indicating that the record has been locked by a transaction, and if "N" indicates that the record is idle, the transaction can access it. Adding a lock tag field is possible.

Use Hibernate version control to achieve optimistic locking

Optimistic locking is a mechanism provided by the program that ensures that multiple transactions concurrently access the data and prevents the second category from losing the update problem.

The version control feature provided by Hibernate can be used in the application to view optimistic locking, <version> elements and <timestamp> in the or mapping file have versioning features, generally recommended <version>

The concept of Java transactions