Spring Learning Notes (17)----Transactions in spring

A transaction is a set of database operations, but this set of operations is atomic (atomic). The so-called atomic operations, that is, this set of database operations are either executed successfully, or not executed. When something succeeds ("success" means that the data in the database has been updated or committed), but there is an exception in the middle, and the back is unable to execute, the transaction is to rollback, that is, to revert to nothing to perform the previous state.

For a more common example, a customer would have to make a bank transfer to transfer $100 from a account to a B account, and the general process would be to subtract the total of account a from the total of the 100,B account plus 100 (consider the simplest case only). An exception occurs after the total of a account minus 100, making it impossible to operate on the B account. If the transaction is not used, the customer loses 100 yuan, but if the transaction is used, then the transaction rolls back after the exception, so that the total of the a account reverts to the amount minus 100. Although the use of transactions did not achieve the purpose of customer transfer, but to avoid the abnormal situation when the customer's loss.

Business is the equivalent of doing one thing (it's a lot of small steps), or we're going to do it all the way through, or we don't do it at all. Can't do half a stall to quit.

Back in spring, Spring's DAO framework provides powerful support for transactions. It includes two kinds of things management, namely:

• Programmatic things management (programmatic tansaction management)

• Declarative things management (declarative tansaction Management)

The so-called programmatic management of things is to put the management of things in the form of code into your application to use things to manage the place, the flexibility is strong. Declarative things management is defined in the XML file as a configuration file, with the benefit of not having code intrusion, and when things are not being managed, you can directly modify the configuration file without having to modify the code. These two kinds of things will be managed later.

In spring, there are several things that are related to the following properties:

1. Communication Act (propagation behavior)

It is the definition of the beginning, the pause, the end of the thing, mainly the following kinds of

parameters	meaning
propagation_required	If there is something, continue this thing, if it does not exist, create a new thing.
propagation_supports	If there are things, continue this thing, and if it does not exist, do it in a non-transactional way.
propagation_mandatory	must be executed in an existing thing, or an exception will be thrown.
propagation_requires_new	Create a new thing, and if one exists, pause it.
propagation_not_supported	No longer executes in the transaction and pauses it if there is an existing thing.
propagation_never	No longer executes in the transaction, and throws an exception if there is an existing thing.
propagation_nested	Execute in an embedded thing, otherwise propagation_required

The above parameters are defined in the Org.springframework.transaction.TransactionDefinition interface (the type is public static final with a value from 0 to 6). The most common of the above parameters is propagation_required.

2. Isolation class (Isolation level)

In an application application, there may be multiple transactions running, which can cause problems.

• Dirty Read

One thing updates some data in a database, another thing reads it, and the previous thing rolls back for some reason, the second thing reads "Dirty data".

• Non-repeatable Read

A thing needs two times to query the same data, but there may be another thing in the middle of two queries that changes the data, causing the data to be read out of the previous two times inconsistent.

• Phantom read

One thing queries the same table two times, but there may be another thing in the middle of the two query that inserts some new data into the table, causing the two queries of the previous thing to be inconsistent.

To solve these problems, spring's things management defines some isolation levels, called "isolation," which is the locking of data.

Parameters	Meaning
Isolation_default	Using the database default isolation level
isolation_read_uncommitted	Allow things to read data that is not yet committed by other parallel things. There are three cases of this level.
isolation_read_committed	Allow things to read other parallel things have committed (commit) data, can prevent dirty read
Isolation_repeatable_read	This level can prevent the above three cases from occurring.
Isolation_serializable	Using a lock of things, locking the corresponding data, can prevent the above three cases, but the efficiency is low.

The above parameters are also defined in the Org.springframework.transaction.TransactionDefinition interface (the type is public static final with a value of -1,1,2,4,8). The most common of the above parameters is isolation_default.

3. Read Only

When this property is applied, the underlying database can be optimized for reading, but used in conjunction with propagation_required,propagation_requires_new or propagation_nested, which can only be used in things.

4. Timeout

In the case of multiple things in parallel, in order to ensure correctness, some things operate with delay, or even deadlock. Set the time-out period to avoid long waits for things. Set the thing timeout to be used in conjunction with propagation_required,propagation_requires_new or propagation_nested.

The above four properties and their corresponding methods are defined in the Org.springframework.transaction.TransactionDefinition interface and its implementation class (such as Org.springframework.transaction.support.De faulttransactiondefinition).

Spring Learning Notes (17)----Transactions in spring