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

Today, the editor will show you how to analyze common problems in Spring declarative affairs. The knowledge points in the article are introduced in great detail. Friends who feel helpful can browse the content of the article with the editor, hoping to help more friends who want to solve this problem to find the answer to the problem. Let's follow the editor to learn more about "how to analyze frequently asked problems in Spring declarative affairs".

Declarative transaction is a very important function of spring, which can prevent development from falling into tedious transaction control logic. But it may be too convenient for many people to understand the principle of spring transactions, so it is necessary to do some analysis.

The following is described in the interceptor configuration.

First, look at the configuration file:

PROPAGATION_REQUIRED,readOnly,-Exception PROPAGATION_REQUIRED,-Exception PROPAGATION_NOT_SUPPORTED,readOnly,-Exception PROPAGATION_SUPPORTS -Exception true * Service

The AOP proxy autoProxyCreator is introduced in the configuration step, which uses spring's default jdk dynamic proxy BeanNameAutoProxyCreator.

There are two attributes to introduce:

1. Intercept range beanNames

In the example, the blocking scope is * Service, which means the bean ending in Service in the IOC container, which is generally configured in a spring configuration file such as spring.xml,serviceContext.xml.

Note that this is not the class under the value src.

Bean configuration Information:

There is a picture and the truth, the following is the BeanNameAutoProxyCreator debugging information.

2. Cutter interceptorNames

InterceptorNames defines transaction attributes and transaction managers.

The second step in configuration is to define transaction attributes: transaction propagation scope, transaction isolation level.

There is nothing to say about transaction attributes. Anyone who uses spring for transaction management knows that there is a lot of information on the Internet.

Step 3, specify the transaction manager.

HibernateTransactionManager,spring is used here to provide transaction support for common orm. From the spring source code, you can see that HibernateTransactionManager.doGetTransaction () supports both hibernate and jdbc. Support hibernate and jdbc mixed transactions, without using jta, there is a prerequisite: using the same data source, the same data source here means not only the same physically, but also the same in the spring configuration file. I encountered this problem in the development. I first defined a data source that both baseDataSource,hibernate and jdbc use this data source. Later, the project required the use of a dynamic data source with another data source dynamicDataSource only changed under hibernate, without changing the corresponding configuration of jdbc, resulting in transaction control problems.

An error occurred with the transaction configuration:

Dao profile:

Both hibernate and jdbc operations are supported in dao.

II. Propagation of transaction attributes

Let's first take a look at such a list:

1. AOP transaction control based on jdk dynamic agent can only be aimed at interfaces.

The transaction properties set in the configuration file above have no effect on A3 (). A3 () cannot design transaction properties alone, but can only inherit the transaction properties of interface methods.

2. The transaction of the class itself is nested

* cases:

AbcIService abcService; BcdIService bcdService; abcService.a1 (); abcService.a2 (); bcdService.b1 ()

The transaction properties corresponding to these three methods all work.

The second situation:

Method definition

Public void A1 () {bcdService.b1 ();}

Call:

AbcService.a1 ()

Results:

AbcService.a1 (); bcdService.b1 ()

The transaction properties corresponding to both methods work.

The third situation:

Method definition

Public void A1 () {this.a2 ();}

Call:

AbcService.a1 ()

Results:

AbcService.a1 (); abcService.a2 ()

The transaction attribute configuration corresponding to a2 () does not work.

Solution:

1) detach a2 () into another class

Disadvantages: trouble, will split the relevant business logic

2) call without this.a2 (), but with abcService.a2 ()

Public void A1 () {abcService.a2 ();}

Cons: inject self-references into the class.

Cause analysis:

Why did this happen?

When we call abcService.a1 ();, the abcService is fetched from the IOC container and AbcServiceImpl instead of its dynamic proxy AbcServiceProxy.

As shown in the schematic diagram, spring is not necessarily implemented in this way, but the principle is the same.

The AbcServiceProxy.a () method is enhanced by AOP, adding transaction control based on the transaction attributes in the configuration file.

Public void A1 () {this.a2 ();}

This.a2 () here this means that AbcIServiceImpl does not use AOP enhancements, so there is no need to apply transaction attributes, only the transaction attributes of A1 () are inherited.

Public void A1 () {abcService.a2 ();}

AbcService is actually AbcServiceProxy.a2 (), so you can apply transaction attributes.

So to make method nested calls within the class, if the nested method a2 () needs to be different from the transaction attribute of the nested method A1 (), it needs to be: 1) exposed on the interface; 2) called through a proxy.

Thank you for your reading, the above is the whole content of "how to analyze frequently asked questions in Spring declarative affairs". Friends who learn to learn to do it quickly. I believe that the editor will certainly bring you better quality articles. Thank you for your support to the website!

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.