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

This article mainly explains the "spring-related knowledge points and interview content", the content of the explanation is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "what are the spring-related knowledge points and interview content" bar!

Sping transactions only take effect on exceptions of RuntimeException and Error types, but not on checked exceptions is the exception caught by try catch.

The process of transaction rollback catches exceptions and determines the exception type. if it is RuntimeException and Error, do the roll back operation.

Status.hasSavepoint () if there is a savePoint in status, only roll back to savePoint!

Status.isNewTransaction () if status is a new transaction, it will really roll back!

Status.hasTransaction () if status has a transaction, it will mark the transaction in staus!

2 Core Interface

There are many details in the implementation of Spring transaction management, and it will be very helpful for us to understand transactions if we have a general understanding of the whole interface framework. Let's explain the transaction interface of Spring to understand the specific strategy of Spring to implement transactions.

The interfaces involved in Spring transaction management are linked as follows:

2.1 platform transaction Manager (PlatformTransactionManager)

Spring does not manage transactions directly, but provides a variety of transaction managers, which delegate the responsibility of transaction management to transactions of the relevant platform framework provided by persistence mechanisms such as Hibernate or JTA.

The interface of the Spring transaction manager is org.springframework.transaction.PlatformTransactionManager

Through this interface, Spring provides corresponding transaction managers for various platforms, such as JDBC, Hibernate, etc., but the specific implementation is the business of each platform.

The content of the PlatformTransactionManager API is shown in the figure above:

It mainly defines

GetTransaction (TransactionDefinition definition) / / get transaction

Commit () / / submit

Rollback () / / rollback

Method.

And the specific implementation, we commonly used are:

DataSourceTransactionManager: manage transactions when using jdbc for database operations

HibernateTransactionManager: manage transactions when operating with hibernate.

2.2 basic transaction attribute definition (TransactionDefinition)

The transaction manager interface PlatformTransactionManager mentioned above uses the getTransaction (TransactionDefinition definition) method

Pass in the transaction attribute definition to get the transaction

The parameter in this method is the TransactionDefinition class, which defines some basic transaction properties.

So what are transaction attributes?

Transaction attributes can be understood as some basic configuration of the transaction, describing how the transaction strategy is applied to the method. The transaction attribute contains five aspects.

The contents of the TransactionDefinition API:

It mainly defines

GetPropagationBehavior () / / get transaction propagation behavior

GetIsolationLevel () / / get the transaction isolation level

GetTimeout () / / get the timeout

IsReadOnly () / / whether the transaction is read-only

We can find that TransactionDefinition is just used to define transaction attributes, which are described in more detail below.

2.2.1 Communication behavior

The first aspect of a transaction is the propagation behavior (propagation behavior).

When a transaction method is called by another transaction method, you must specify how the transaction should be propagated.

Spring defines seven propagation behaviors:

Communication behavior

Meaning

PROPAGATION_REQUIRED

Indicates that the current method must run in a transaction. If the current transaction exists, the method will run in that transaction. Otherwise, a new transaction will be started

PROPAGATION_SUPPORTS

Indicates that the current method does not require a transaction context, but if there is a current transaction, the method will run in that transaction

PROPAGATION_MANDATORY

Indicates that the method must run in a transaction, and if the current transaction does not exist, an exception will be thrown

PROPAGATION_REQUIRED_NEW

Indicates that the current method must run in its own transaction. A new transaction will be started. If there is a current transaction, the current transaction is suspended during the execution of the method. If you are using JTATransactionManager, you need to access TransactionManager

PROPAGATION_NOT_SUPPORTED

Indicates that the method should not run in a transaction. If there is a current transaction, the current transaction is suspended while the method is running. If you are using JTATransactionManager, you need to access TransactionManager

PROPAGATION_NEVER

Indicates that the current method should not run in the context of a transaction. If a transaction is currently running, an exception is thrown

PROPAGATION_NESTED

Indicates that if a transaction already exists, the method will run in a nested transaction. Nested transactions can be committed or rolled back independently of the current transaction. If the current transaction does not exist, it behaves like PROPAGATION_REQUIRED. Note that the support of different manufacturers for this kind of communication behavior is different. You can refer to the documentation of the resource manager to confirm that they support nested transactions

You can see that there are seven transaction propagation behaviors mentioned above, and the three that are often used are marked in red. REQUIRED is one of the most frequently used.

2.2.2 isolation level

The second dimension of transactions is the isolation level (isolation level).

The isolation level defines the extent to which one transaction may be affected by other concurrent transactions.

Spring defines five isolation levels:

Isolation level

Meaning

ISOLATION_DEFAULT

Use the default isolation level of the back-end database

ISOLATION_READ_UNCOMMITTED

The lowest isolation level that allows uncommitted data changes to be read, which may result in dirty, phantom, or unrepeatable reads

ISOLATION_READ_COMMITTED

Allow reading of data that has been committed by concurrent transactions, which can prevent dirty reads, but phantom or unrepeatable reads can still occur

ISOLATION_REPEATABLE_READ

The results of multiple reads to the same field are consistent, unless the data is modified by the transaction itself, which can prevent dirty reading and non-repeatable reading, but phantom reading can still occur.

ISOLATION_SERIALIZABLE

The highest isolation level, which is fully compliant with the ACID isolation level, ensures that dirty, unrepeatable, and phantom reads are prevented, and is also the slowest transaction isolation level, as it is usually achieved by fully locking transaction-related database tables

In Spring, DEFAULT is used by default, which is the isolation level of the database used in the current connection pool.

The default isolation level for Oracle is: READ_COMMITTED

The default isolation level for Mysql is: REPEATABLE_READ

2.2.3 read-only

The third feature of a transaction is whether it is a read-only transaction.

If the transaction only does this to the back-end database, the database can take advantage of the read-only nature of the transaction to make some specific optimizations.

By making the transaction read-only, you can give the database a chance to apply the optimizations it deems appropriate.

2.2.4 transaction timeout

In order for the application to run well, the transaction cannot run for too long.

Because transactions may involve locking to the back-end database, long-term transactions can unnecessarily take up database resources.

A transaction timeout is a timer for a transaction, and if the transaction does not finish execution within a certain period of time, it will be automatically rolled back instead of waiting for it to end.

2.2.5 Roll back rules

The last aspect of the transaction Pentagon is a set of rules that define which exceptions cause the transaction to roll back and which do not.

By default, transactions are rolled back only if they encounter run-time exceptions, but not when they encounter check-type exceptions (this behavior is consistent with EJB's rollback behavior)

But you can declare that the transaction rolls back as it encounters a run-time exception when it encounters a specific check-type exception. Similarly, you can declare that a transaction does not roll back when it encounters specific exceptions, even if those exceptions are run-time exceptions.

2.3 transaction status

The method described above that calls getTransaction () of the PlatformTransactionManager interface results in an implementation of the TransactionStatus interface.

The content of the TransactionStatus API is shown in the figure above:

It mainly defines

IsNewTransaction (); / / is it something new?

HasSavepoint (); / / whether there is a recovery point

SetRollbackOnly (); / / set to rollback only

IsRollbackOnly (); / / whether it is rollback only

Whether isCompleted; / / has been completed

It can be found that this interface describes some transaction processing methods that provide simple methods to control transaction execution and query transaction status, which needs to be applied when rollback or commit.

3 the implementation of transactions 3.1 the difference between programming and declarative transactions

Spring provides two implementation methods: programmatic transaction and declarative transaction.

Programmatic transactions allow users to precisely define the boundaries of transactions in their code

Declarative transactions (based on AOP) help users decouple actions from transaction rules.

To put it simply, programmatic transactions invade the business code, but provide more detailed transaction management; while declarative transactions, based on AOP, can not only play the role of transaction management, but also do not affect the specific implementation of the business code.

Thank you for your reading, the above is the content of "spring-related knowledge and interview content". After the study of this article, I believe you have a deeper understanding of spring-related knowledge and interview content, and the specific use needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.