1、 Spring other
- Atomicity: a transaction is an indecomposable unit. All operations in the transaction are either done or not done. Atomicity emphasizes the whole of affairs;
- Consistency: after the transaction is executed, all data should remain consistent. Consistency emphasizes the integrity of data;
- Isolation: when multiple database operations are executed concurrently, a requested transaction operation cannot be disturbed by other operations, and multiple concurrent transaction executions should be isolated from each other. Isolation is emphasized;
- Persistence: after the transaction is completed, its impact on the data is permanent. Persistence emphasizes the results of operations.
Transaction concurrent operation:
- Dirty read: one transaction reads data that is not committed by another transaction;
- Non repeatable reading: when one transaction reads the data submitted for modification by another transaction, it queries the data in the same row twice, and the results are inconsistent;
- Phantom reading: when a transaction reads the new data submitted by another transaction, it queries the same table twice, and new rows appear, resulting in inconsistent results.
Isolation level of transaction:
- Read uncommitted – no problem is solved;
- Read committed – resolve dirty reads;
- Repeatable read – solve the problem of dirty reading and non repeatable reading;
- Serializable serialization — solve dirty reading, non repeatable reading and unreal reading.
There are four isolation levels. The top-down level increases step by step, but the concurrency performance decreases step by step. The default transaction isolation level in MySQL is repeatable read, and the default transaction isolation level in Oracle and postgressql is read committed.
1.2 transaction communication behavior
- Required: required [default]: This is the default behavior of transaction propagation behavior in spring framework. Its definition is: if there is no transaction running at present, a new transaction will be started; If there is already a transaction running, the method will run in the current transaction. Simple summary:You didn’t, I opened it; You have, I’ll join。
- REQUIRES_ New: new transaction: new transaction. As the name suggests, it must be a new transaction. Its definition can be described as: if there is no transaction running at present, a new transaction will be started; If there is already a transaction running, the original transaction will be suspended (suspended) and a new transaction will be restarted. When the new transaction is completed, release the original transaction. Simple summary:You didn’t, I opened it; You have it. I’ll make a new one。
- Supports: support: the word “support” is compared with the word “must”, and the degree of importance is clear at a glance. The supported definitions are: if there is a transaction running, the method will run in the current transaction; If no transaction is currently running, no new transaction is created (that is, it is not running in a transaction). Obviously, support is more inclined to an indifferent attitude, so a simple summary is:Yes, there is. I didn’t pull it down。
- NOT_ Supported: not supported: not supported. Obviously, it is completely opposite to the above. Its definition is: if there is a transaction running, the transaction will be suspended (suspended); If no transaction is currently running, it will not run in a transaction. This attitude doesn’t matter. It’s not rare when there are affairs. To sum up simply:Yes, I don’t want it. No, it’s just right。
- Mandatory: mandatory: this attitude sounds very anxious and tough. It means that the current method must run in a transaction. If there is no transaction, an exception will be thrown directly. Good guy, this is too fierce. If there is no transaction when the current method is executed, it will not work directly. So let’s briefly summarize:If you want to work, you must have it. If you don’t, you’ll kill it。
- Never: not allowed: another pair of completely opposite designs. Never defines that the current method is not allowed to run in a transaction. If there is already a transaction running, an exception will be thrown. This guy is the same as the above mandatory, but the two attitudes are completely opposite. Its simple summary is:If you have to work, you are not allowed to work. If you have to, you are not allowed to work。
- Nested: nested: this nested is the most special. It is the propagation behavior based on savepoint. Its definition is: if there is no transaction running at present, start a new transaction; If a transaction is already running, a savepoint will be recorded and continue to run in the current transaction. If an exception occurs during the operation of a sub transaction, it will not be rolled back completely, but will be rolled back to the previous savepoint. It can be found that this design is the design of the savepoint, so a simple summary can be as follows:If you don’t, I open it. If you have it, you write it down; I’m gone, you go again, I hang up, as if nothing had happened。
1.3 spring transaction control model
- Platform transaction manager: platform transaction manager
- Transaction definition: transaction definition
- Transactionstatus: transaction status
In short, the control of transactions by the spring framework can be understood as a transaction manager, which can obtain / control the state of transactions according to the definition of transactions.
1.4 transaction listener
- BEFORE_ Commit: trigger listening before the transaction is committed
- AFTER_ Commit: trigger listening after a transaction is committed (default)
- AFTER_ Rollback: trigger listening after transaction rollback
- AFTER_ Completion: trigger listening after the transaction is completed (whether committed or rolled back)
1.5 distributed transactions
Distributed transaction refers to the transaction completed by remote cooperation between different application / relational databases through the network.
- Global transaction manager: a transaction manager that controls the whole distributed transaction. It can control the transaction submission or rollback on each node branch in a distributed transaction
- Resource Manager: it can be simply understood as relational database
- Application: our own program
2pc is a two-phase commit protocol, which decomposes the commit action of a transaction into two phases: prepare and commit.
- Dispatcher servlet: the core CPU, which is responsible for receiving requests, distributing them, and giving responses to clients
- Handler mapping: the processor mapper matches and finds the handler that can be handled according to the URI, and encapsulates the interceptor involved in the request together with the handler
- Handleradapter: the processor adapter adapts and executes the corresponding handler according to the handler found by handlerapping
- Viewresolver: the view parser parses and renders the real view according to the logical view / view returned by the handler, and passes it to the dispatcher servlet response client
- Handler: the processor that handles the actual request
Root container and servlet sub container:
for an application based on springwebmvc, it hopes to put the service, Dao and other classes into the root container and the controller and related components of the presentation layer into the sub container of the servlet, so as to form a hierarchical relationship.
the design of this parent-child container has two main advantages: first, after the hierarchical relationship is formed, the controller can get the service, but the service can’t get the controller, which can form an isolation; Second, if there is a special case that multiple dispatcherservlets need to be registered, there is no need to register multiple sets of services and Dao. Each sub container of webmvc can take services and Dao from this root container.
- Interceptor is the concept of framework, while filter is the concept of servlet
- The filter can intercept almost all requests, while the interceptor can only intercept requests received and processed by the dispatcher servlet
- The interceptor can obtain the required beans by dependency injection, while the filter cannot obtain them by normal means
- Prehandle: triggered before executing the controller method. It can be used for encoding, permission verification and interception
- Posthandle: triggered after executing the controller method and before jumping to the page / returning JSON data
- It can be used to monitor the performance of the controller after the exception is triggered
The prehandle method is executed sequentially, and the posthandle and aftercompletion methods are executed in reverse order.