Home > Java > javaTutorial > What does java transaction mean?

What does java transaction mean?

(*-*)浩
Release: 2019-05-21 17:27:52
Original
2767 people have browsed it

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

What does java transaction mean?

1. 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.

Atomic. 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 the transaction was executed. No state transition occurs.

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, before 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.

Run an embedded SQL application or script, and the transaction will automatically start when the executable SQL statement is executed for the first time (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 a COMMIT statement is executed, all changes made to the database since the transaction was initiated 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. When the database system completes executing a SQL After the statement, the transaction is automatically committed.Manual commit mode: The transaction start boundary and end boundary 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 summarized into the following categories:

The first type of lost update: when a transaction is revoked, the update 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 non-repeatable read and the second type of lost update concurrency problems, which can be applied in the application Pessimistic locking or optimistic locking is used in the program to avoid such problems. From an application perspective, locks can be divided into the following categories:

Serializable: A transaction cannot see the updates made to the database by other transactions during execution. Repeatable Read: During execution, a transaction can see newly inserted records that have been submitted by other transactions, but it cannot see updates to existing records by other transactions. Read Committed (read committed data): During the execution of a transaction, you can see newly inserted records that have been committed by other transactions, and you can also see updates to existing records that have been committed by other transactions. 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 updates to existing records that have not been committed by other transactions.

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 program, locks can be divided into the following categories:

A. Pessimistic lock: refers to the locking of data resources displayed in the application program. 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 level of the database to automatically manage the lock work. Applications use version control to avoid possible concurrency issues.

5. There are two ways to implement pessimistic locking.

A. Display in the application program and specify the exclusive use of the 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 in the database table A LOCK field indicating the record status. 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.

Use Hibernate 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.

You can use the version control function provided by Hibernate to implement optimistic locking in the application. The element and in the OR mapping file both have version control functions. It is generally recommended to use < version>

The above is the detailed content of What does java transaction mean?. For more information, please follow other related articles on the PHP Chinese website!

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template