Shulou(Shulou.com)06/01 Report--

Most people do not understand the knowledge points of this article "what are the characteristics of transactions in java?", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this article "what are the characteristics of transactions in java?"

There are four characteristics of transactions in Java: atomicity, consistency, isolation and persistence.

Atomicity: if you execute a sql, the underlying layer executes the transaction by default, which is called invisible transaction. When executing multiple sql statements, multiple sql statements cannot be split. They must be executed all at once, that is, either all of them are completed or fail.

Consistency: after the completion of the transaction, the data state remains consistent, the law of conservation of energy, ha.

Isolation: multiple transactions access the database concurrently. Transactions modify data and need to be isolated from other transactions.

Persistence: data modification completed, data persistent storage

To use JDBC, you need to close the actively committed transaction first, then execute multiple SQL statements, and then commit. If an error is reported to roll back the transaction, automatic commit will be started at last, because when a sql statement is executed, the transaction will also be opened, which is called invisible transaction, and commit will be carried out by default. If the transaction is turned off and not started, later execution of a SQL also needs to show the transaction.

Connection conn = openConnection (); try {/ / turn off autocommit: conn.setAutoCommit (false); / / execute multiple SQL statements: insert (); update (); delete (); / / commit transaction: conn.commit ();} catch (SQLException e) {/ / rollback transaction: conn.rollback ();} finally {conn.setAutoCommit (true); conn.close ();}

There are four Mysql isolation levels: Read Uncommitted (read uncommitted), Read Committed (read committed), Repeatable Red (repeatable read), and Serializaable (serialization)

Isolation Level dirty reading (Dirty Read) unrepeatable (Non Repeatable Read) phantom reading (Phantom Read) Read UncommittedYesYesYesRead Committed-YesYesRepeatable Read--YesSerializable

Read Uncommitted is the transaction level with the lowest isolation level. At this isolation level, one transaction reads data updated by another transaction but not committed, and if another transaction rolls back, then the data read by the current transaction is dirty data, which is called dirty read (Dirty Read).

Mysql > select * from students;+----+-+ | id | name | +-+-+ | 1 | Alice | +-+-+ 1 row in set (0.00 sec)

Then, open two MySQL client connections, and execute transaction An and transaction B sequentially:

When transaction A completes step 3, it updates the record of the id=1 but does not commit, and the data read by transaction B in step 4 is the uncommitted data.

Subsequently, transaction A rolls back in step 5, and transaction B reads the id=1 record again and finds that the data is inconsistent with the last read, which is dirty reading.

It can be seen that under the Read Uncommitted isolation level, one transaction may read data updated by another transaction but not committed, which may be dirty data.

Moment transaction A transaction B1SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;2BEGIN;BEGIN;3UPDATE students SET name = 'Bob' WHERE id = 1x 4SELECT * FROM students WHERE id = 1x 5ROLLBACKTOR 6SELECT * FROM students WHERE id = 1X 7COMIT

Under the Read Committed isolation level, a transaction may encounter unrepeatable read (Non Repeatable Read) problems.

Unrepeatable reading means that the same data is read many times within a transaction, and if another transaction happens to modify the data before the end of the transaction, the data read two times may be inconsistent in the first transaction.

Let's still prepare the data for the students table first:

Mysql > select * from students;+----+-+ | id | name | +-+-+ | 1 | Alice | +-+-+ 1 row in set (0.00 sec)

Then, open two MySQL client connections, and execute transaction An and transaction B sequentially:

When transaction B executes the query in step 3 for the first time, the result is Alice, and then, because transaction A updates the record and commits it in step 4, the result becomes Bob when transaction B executes the same query again in step 6. Therefore, under the Read Committed isolation level, transactions cannot read the same record repeatedly, because the results are likely to be inconsistent.

Instant transaction A transaction B1SET TRANSACTION ISOLATION LEVEL READ COMMITTED;SET TRANSACTION ISOLATION LEVEL READ COMMITTED;2BEGIN;BEGIN;3SELECT * FROM students WHERE id = 1bot 4UPDATE students SET name = 'Bob' WHERE id = 1x 5COMMIT * FROM students WHERE id = 1x 7COMMIT

Under the Repeatable Read isolation level, a transaction may encounter Phantom Read problems.

Phantom reading means that in a transaction, the first time you query a record and find that there is no record, but when you try to update this non-existent record, it is successful, and, when you read the same record again, it miraculously appears.

Let's still prepare the data for the students table first:

Mysql > select * from students;+----+-+ | id | name | +-+-+ | 1 | Alice | +-+-+ 1 row in set (0.00 sec)

Then, open two MySQL client connections, and execute transaction An and transaction B sequentially:

When transaction B reads the record of id=99 for the first time in step 3, the read record is empty, indicating that there is no record of id=99. Transaction A then inserts an id=99 record and commits it in step 4. When transaction B reads id=99 's record again in step 6, the read record is still empty, but transaction B succeeds when it tries to update this non-existent record in step 7, and when transaction B reads id=99 's record again in step 8, the record appears.

It can be seen that phantom reading is a record that has not been read, thinking that it does not exist, but in fact, it can be updated successfully, and, after the update is successful, it is read again, and it appears.

Instant transaction A transaction B1SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;2BEGIN;BEGIN;3SELECT * FROM students WHERE id = 99th 4INSERT INTO students (id, name) VALUES (99, 'Bob'); 5COMMITIT6SELECT * FROM students WHERE id = 99X 7UPDATE students SET name =' Alice' WHERE id = 99th 8SELECT * FROM students WHERE id = 99 X 9COMMIT

Serializable is the strictest isolation level. Under the Serializable isolation level, all transactions are executed sequentially, so dirty reads, unrepeatable reads, and phantom reads do not occur.

Although transactions under the Serializable isolation level have the highest security, because transactions are executed serially, there is a significant decline in efficiency and a sharp drop in application performance. If there are no particularly important scenarios, the Serializable isolation level is generally not used.

Default isolation level

If no isolation level is specified, the database uses the default isolation level. In MySQL, if you use InnoDB, the default isolation level is Repeatable Read.

Start a transaction

Add an annotation @ EnableTransactionManagement to the startup class

Use @ Transactional (isolation = Isolation.DEFAULT,propagation = Propagation.REQUIRED) to isolate the boundary from the transaction propagation above the method of performing the transaction. The default is REQUIRED.

Transaction propagation

Spring's declarative transaction defines several levels for transaction propagation, and the default propagation level is REQUIRED, which means that if there is no current transaction, a new transaction is created and, if there is one, added to the current transaction for execution.

SUPPORTS: means that if there is a transaction, it will be added to the current transaction, and if not, transaction execution will not be enabled. This propagation level can be used for query methods because SELECT statements can be executed within a transaction or do not require a transaction

MANDATORY: indicates that the current transaction must exist and join the execution, otherwise an exception will be thrown. This propagation level can be used for core update logic, such as user balance changes, which is always called by other transaction methods and cannot be called directly by non-transaction methods.

REQUIRES_NEW: indicates that a new transaction execution must be started regardless of whether there is a transaction or not. If there is already a transaction, the current transaction will be suspended and resume execution after the new transaction is completed

NOT_SUPPORTED: indicates that transactions are not supported. If there is a transaction, the current transaction will be suspended. After the execution of this method is completed, execution will resume.

NEVER: compared with NOT_SUPPORTED, it not only does not support transactions, but also refuses to execute when a current transaction is detected.

NESTED: indicates that if there is a current transaction, a nested-level transaction is opened, and if there is no transaction, a new transaction is opened.

The above is about the content of this article on "what are the characteristics of transactions in java?" I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.