Deeply analyze the distinction between mixed transactions and beans in Java’s spring framework

Mixed transactions are within the transaction of the transaction manager of the ORM framework. Using the jdbctemplate to execute SQL will not be included in the transaction management. Let's analyze the source code to see why the jdbctemplate must be used in the transaction of the data source transaction manager.

1. Start the transaction datasourcetransactionmanager

The dobegin () method will bind the database connection that has opened the transaction to a ThreadLocal variable with the data source name as key and the connectionholder (saving the connection) as value.

2. Binding connection

The resources variable is the ThreadLocal variable mentioned above, so that subsequent jdbctemplate can use datasource as the key to find the database connection.

3. Execute SQL jdbctemplate

4. Get the connection datasourceutils

It can be seen that datasourceutils is also connected through the transaction synchronization manager. Therefore, as long as the jdbctemplate and the datasourcetransactionmanager have the same datasource, they will be able to get the same database connection, and naturally they can correctly commit and rollback transactions. Take hibernate as an example to illustrate the problems mentioned at the beginning and see why the transaction manager of ORM framework can not manage jdbctemplate.

5 ORM transaction manager hibernate transaction manager

Because the ORM framework does not directly inject the datasource into the transaction manager, but uses its own sessionfactory and other objects to operate the datasource like the hibernate transaction manager above. Therefore, although the underlying data sources of sessionfactory and jdbctemplate may be the same, because different keys are used when binding in transactionsynchronizationmanager (one is sessionfactory name and the other is datasource name), the database connection of the transaction opened by ORM transaction manager cannot be obtained during the execution of jdbctemplate.

Bean distinguishes the spring configuration file in a public project, which may be referenced by multiple projects. Because each project may only need some beans in the public project, when the spring container of these projects starts, it is necessary to distinguish which beans to create. 1. An application example takes a section of the configuration in the Apache open source framework jetspeed as an example: page manager xml

2. Bean filterjetspeedbeandefinitionfilter will take out the value corresponding to J2: cat in the bean configuration above when the spring container parses each bean definition, such as dbpagemanager pageserializer. Then match this part with the current key (read from the configuration file) as a regular expression. Only the matched bean will be created by the spring container. JetspeedBeanDeFinitionFilter

Category in match() method_ Meta_ The value of key is J2: cat. The matcher class stores the current key and is responsible for matching the current key with the regular expression of each bean. Registerdynamicalias is used to register aliases for beans by calling this method after bean matching is successful. See the source code in 1.3 below for details.

3. Customize the spring container, customize a spring container, override the registerbeandefinition () method, and intercept when spring registers beans.

4. Alias the bean, use the beanreferencefactorybean factory bean, and wrap the two beans configured above (xmlpagemanager and dbpagemanager). Configure the key into its own implementation, and switch the two implementations by configuring the current key. All aliases are matched into one, so that the beans that refer to them can directly refer to this alias. For example, the following pagelayoutcomponent. page-manager. xml