Pessimistic locking and optimistic locking of the database:
Pessimistic (one lock, two checks, three updates): it can be implemented by select * from ... for update; different databases have different implementation and support for select for update. For example, Oracle supports select for update no wait, indicating that If you can't get the lock and report an error immediately, instead of waiting, mysql will block without the no wait option. Another problem with MySQL is that all scanned rows in the execution of the select for update statement will be locked, which can easily cause problems. Therefore, if you use pessimistic locking in mysql, you must make sure that the index is gone, not a full table scan.
Optimistic locking: It can be achieved by adding field version or field timestamp to the table, that is, where the original version number is brought when updating.
1. Propagation (propagation properties of transactions)
Propagation : The key property determines which method the proxy should add transactional behavior to. The most important part of such a property is the propagation behavior. The following options are available:
PROPAGATION_REQUIRED--Support the current transaction, if there is no current transaction, create a new transaction. default.
PROPAGATION_SUPPORTS--Support the current transaction, if there is no current transaction, it will be executed in a non-transactional manner.
PROPAGATION_MANDATORY--Supports the current transaction, if there is no current transaction, an exception is thrown.
PROPAGATION_REQUIRES_NEW--Create a new transaction, if there is a current transaction, suspend the current transaction.
PROPAGATION_NOT_SUPPORTED--Perform the operation in a non-transactional manner, suspending the current transaction if there is a current transaction.
PROPAGATION_NEVER--Execute in a non-transactional manner, throwing an exception if there is currently a transaction.
1： PROPAGATION_REQUIRED
Join the current transaction to be executed is not in another transaction, then start a new transaction
For example, if the transaction level of ServiceB.methodB is defined as PROPAGATION_REQUIRED, then when ServiceA.methodA is executed,
ServiceA.methodA has already started a transaction. At this time, ServiceB.methodB is called. ServiceB.methodB sees that it is already running in ServiceA.methodA
Inside the transaction, no new transaction will be started. And if ServiceA.methodA runs and finds that he is not in a transaction, he will assign himself a transaction.
This way, if an exception occurs in ServiceA.methodA or anywhere within ServiceB.methodB, the transaction will be rolled back. Even if ServiceB.methodB's transaction has been
Submit, but ServiceA.methodA will be rolled back next fail, and ServiceB.methodB will also be rolled back
2： PROPAGATION_SUPPORTS
If it is currently in a transaction, that is, it is running in the form of a transaction. If it is not currently in a transaction, it is running in a non-transactional form.
3： PROPAGATION_MANDATORY
Must run within a transaction. That is, he can only be called by a parent transaction. Otherwise, he will throw an exception
4： PROPAGATION_REQUIRES_NEW
This is rather convoluted. For example, we design the transaction level of ServiceA.methodA to be PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB to be PROPAGATION_REQUIRES_NEW.
Then when ServiceB.methodB is executed, the transaction where ServiceA.methodA is located will be suspended, ServiceB.methodB will start a new transaction, and after the transaction of ServiceB.methodB is completed,
He just continued. The difference between him and the PROPAGATION_REQUIRED transaction is the degree of rollback of the transaction. Because ServiceB.methodB is a new transaction, then there is
two different transactions. If ServiceB.methodB has been submitted, then ServiceA.methodA fails and rolls back, but ServiceB.methodB will not roll back. Rollback if ServiceB.methodB fails,
If the exception he throws is caught by ServiceA.methodA, the ServiceA.methodA transaction may still commit.
5： PROPAGATION_NOT_SUPPORTED
Transactions are not currently supported. For example, the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, while the transaction level of ServiceB.methodB is PROPAGATION_NOT_SUPPORTED,
Then when ServiceB.methodB is executed, the transaction of ServiceA.methodA is suspended, and he finishes running in a non-transactional state, and then continues the transaction of ServiceA.methodA.
6： PROPAGATION_NEVER
Cannot run in a transaction. Assuming that the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NEVER,
Then ServiceB.methodB will throw an exception.
7： PROPAGATION_NESTED
The key to understanding Nested is the savepoint. The difference between him and PROPAGATION_REQUIRES_NEW is that PROPAGATION_REQUIRES_NEW starts another transaction, which will be independent of its parent transaction,
The Nested transaction is dependent on his parent transaction, and his submission is to be submitted together with his parent transaction. That is, if the parent transaction rolls back last, he will also roll back.
And the nice thing about Nested affairs is that he has a savepoint.
Isolation level of Spring transactions
1. ISOLATION_DEFAULT: This is the default isolation level of PlatfromTransactionManager, which uses the default transaction isolation level of the database. The other four correspond to the isolation level of JDBC
2. ISOLATION_READ_UNCOMMITTED: This is the lowest isolation level of the transaction, which allows another transaction to see the uncommitted data of this transaction. This isolation level produces dirty reads, non-repeatable reads and phantom reads.
3. ISOLATION_READ_COMMITTED: To ensure that the data modified by one transaction can only be read by another transaction after it is committed. Another transaction cannot read the uncommitted data of the transaction
4. ISOLATION_REPEATABLE_READ: This transaction isolation level can prevent dirty reads and non-repeatable reads. However, phantom reads may occur. In addition to ensuring that a transaction cannot read uncommitted data of another transaction, it also ensures that the following situation (non-repeatable read) is avoided.
5. ISOLATION_SERIALIZABLE This is the most expensive but most reliable transaction isolation level. Transactions are processed for sequential execution. In addition to preventing dirty reads, non-repeatable reads, it also avoids phantom reads.
What is dirty data, dirty read, non-repeatable read, phantom read?
Dirty read: Refers to when a transaction is accessing data and making modifications to the data, and the modification has not been submitted to the database, at this time, another transaction also accesses the data and then uses the data. Because this data is uncommitted data, the data read by another transaction is dirty data, and operations based on dirty data may be incorrect.
Non-repeatable read: Refers to reading the same data multiple times within a transaction. While this transaction is not over, another transaction also accesses the same data. Then, between two reads of data in the first transaction, due to the modification of the second transaction, the data read twice by the first transaction may be different. In this way, the data read twice in a transaction is different, so it is called non-repeatable read.
Illusionary reading: Refers to a phenomenon that occurs when transactions are not executed independently, for example, the first transaction modifies data in a table, and this modification involves all data rows in the table. At the same time, the second transaction also modifies the data in this table by inserting a new row of data into the table. Then the user who operates the first transaction later finds that there are no modified data rows in the table, as if an illusion occurred.
MySQL transaction isolation level (4):
Among them, the default transaction isolation level of MySQL is: Repeatable Read
But the default transaction isolation level of most database systems is: Read committed
