Understanding of the IOC and transaction manager

1. The concept of dependency injection

Spring's two core concepts: one is the control reversal IOC, or it can be called Dependency Injection di. There is also a facet-oriented programming AOP.

Control reversal: When a Java object needs (depends on) Another Java object, it is created by the container that implements the IOC (such as the IOC container of the spring framework) instead of directly creating the dependent object itself, and injecting it into the Java object that needs the dependent object.

2, Spring's dependency injection

2.1. Constructor Injection

<bean id= "Accoutdaoimpl" class= "Cn.csdn.dao.AccoutDaoImpl" scope= "singleton"/>

<bean id= "Accoutservicimpl" class= "Cn.csdn.service.AccoutServicImpl" scope= "" >

<!--constructor Injection mode--

<constructor-argref= "Accoutdaoimpl"/></bean>

2.2. Set Value (set method) injection

<bean id= "Accountdaoimpl" class= "Cn.csdn.dao.AccoutDaoImpl"/>

<bean id= "Accoutservicimpl" class= "Cn.csdn.service.AccoutServicImpl" >

<!--Set Value (Set method)

<property name= "Accountdaoimpl" ref= "Accoutdaoimpl"/> </bean>

3. Container of Spring

The basic unit of spring management is the bean, in the spring application, so the component is a bean, it can be any Java object. Spring is responsible for creating instances of these beans. and manage the life cycle. The spring framework uses its built-in container to manage the bean, and the bean survives in the spring container, which is only available through some of the methods it provides.

Spring's container has two interfaces: the Beanfactory and ApplicationContext instances of the two interfaces are in the context of spring.

ApplicationContext ac = new Classfathxmlapplicationcontext ("App*.xml");

Accountservice Accountservice = (accountservice) ac.getbean ("Accountserviceimpl");

4. Using XML to assemble beans

4.1. Automatic assembly

No: Automatic assembly is not used. Dependencies must be specified through the ref element, which is the default setting. This setting is recommended for larger deployment configurations, because explicitly specifying collaborators can make the configuration more flexible and clearer. And, in a way, it is also a document form of the system architecture.

<bean id= "Bean1" class= "Cn.csdn.service.Bean1" scope= "singleton" >

<property name= "Studentdaoimpl" ref= "Studentdaoimpl" >

</property></bean>

Note: A property attribute is specified for ref

byname: automatically assembled according to the attribute name. This option examines the container and finds the bean that exactly matches the property, based on its name, and automatically assembles it with the property. For example, Autowire is set to byname in the bean definition, and the bean contains the Master property (which also provides Setmaster (..) method), spring looks for the bean definition named Master and uses it to assemble it to the Master property.

<bean id= "Bean1" class= "Cn.csdn.service.Bean1" scope= "singleton" autowire= "ByName"/>

Note: no property attribute

Bytype: If there is a bean in the container that is the same as the specified property type , it is automatically assembled with this property. If there are more than one bean of that type, an exception is thrown and the automatic assembly cannot be made using the Bytype method. If a matching bean is not found, nothing happens and the property is not set. If you do not want this, then you can set spring to throw an exception by setting dependency-check= "objects".

Note: spring3.0 above does not throw exception.

4.4. Specify the scope of the bean's existence

Singleton : A bean definition corresponds to an object instance in each spring IOC container. This is the default value

prototype: each time the bean A bean definition corresponds to an instance when requested. A bean defines multiple instances.

Request : In an HTTP request, a bean definition corresponds to an instance, that is, each HTTP request will have its own bean instance, which is created from a bean definition. This scope is valid only in the case of a web-based spring ApplicationContext.

Session : In an HTTP session, a bean definition corresponds to an instance. This scope is valid only in the case of a web-based spring ApplicationContext.

global_session : In a global HTTP session, a bean definition corresponds to an instance.

Typically, this is only valid when using the Portlet context. This scope is valid only in the case of a web-based spring ApplicationContext.

4.5. initialization and destruction of the specified bean

Spring can manage the behavior of the bean instance after the instantiation is over and before it is destroyed. The property's Init-method attribute allows you to specify that a method should be executed automatically after the Bean's full dependency setting is complete, and through the property's Destroy-method attribute you can specify that a method should be executed automatically before the bean is destroyed.

4.6. Inheritance of Assembly Bean

If the property assembly information for two beans is similar, you can use inheritance to reduce duplication of configuration effort.

<!--the inherited parent class of the assembly bean as a template, no instantiation is required, set abstract= "true"-

<bean id= "Parent" class= "Cn.csdn.service.Parent" abstract= "true" >

<property name= "name" value= "z_xiaofei168"/>

<property name= "Pass" value= "z_xiaofei168"/></bean>

<!--an inherited subclass of an assembly bean using the Parent property specifies that the parental identity or alias subclass can override the parent class's property assembly, or you can add its own property assembly--

<bean id= "Child" class= "Cn.csdn.service.Chlid" parent= "parent" >

<property name= "Pass" value= "123123"/>

<propertyname= "Age" value= "/></bean>"

Spring the transaction manager

Spring The framework does not directly manage transactions in the user's application system, it simply provides a number of transaction managers for the user to select, and then delegates the responsibility for transaction management to the transactional implementation of the persistence technology corresponding to this transaction manager.  

Transaction Management Implementation	Use time
Org.springframework.jdbc.datasource. Datasourcetransactionmanager	Managing transactions in a single JDBC DataSource
Org.springframework.orm.hibernate3. Hibernatetransactionmanager	Use it to manage jobs when the persistence mechanism is hibernate
Org.springframework.orm. Jpa. Jpatransactionmanager	Use it to manage jobs when JPA is used as a persistence
Org.springframework.transaction. Jta. Jtatransactionmanager	Use a JTA implementation to manage transactions. When a transaction spans multiple resources, you must use the

Transaction Properties Introduction

1>. Propagation Behavior ( 7 each)

Propagation behavior	Description
Propagation_required	must be executed in a transaction. If there is currently a transaction in progress, the method will be executed in that transaction. Otherwise you start a new transaction . The default value for the spring transaction propagation behavior.
Propagation_supports	Support for existing transactions. If no transaction is currently in progress, it is performed in a non-transactional manner
Propagation_mandatory	The method must be in an existing transaction, or an exception will be thrown.
Propagation_requires_new	Must be carried out in its own city affairs. If an existing transaction is in progress, pause it first
propagation_not_supported	Should not be done in the transaction. If an existing transaction is in progress, pause it first
Propagation_never	Should not be done in the transaction. Throws an exception if an existing transaction is in progress
propagation_nested	If an existing transaction is in progress, the method runs in a nested transaction. otherwise propagation_required execution

2>. Isolation Level ( 5 each)

Isolation level	Description
Isolation_default	Use the default isolation level of the underlying database spring transaction ISOLATION level default value
isolation_read_uncommited	Allow another transaction to read UNCOMMITTED data from this transaction can result in dirty reads, non-repeatable reads, and Phantom reads.
isolation_read_commited	Ensuring that one transaction modifies the data before being read by another transaction can result in non-repeatable reads and Phantom reads.
Isolation_repeatable_read	The result of requiring multiple reads of the same field must be the same, unless the transaction itself updates the data that could cause phantom reads.
Isolation_serializable	Transactions are processed for sequential execution to prevent dirty reads, non-repeatable reads, and Phantom reads.

3>. read-only hints

If a transaction only reads back-end data, the back-end database can take some optimizations to improve execution efficiency. However, it must be valid in a transaction. That means to match the propagation behavior propagation_REQUIRED,propagation_requires_new, propagation_nested to set.

4>. transaction time-out interval

You can also set a time-out interval for a transaction so that the transaction automatically rolls back after a specific number of seconds without waiting for it to end itself. Since timing is done at the beginning of a transaction, it also has to be paired with the propagation behavior of propagation_required,propagation_requires_new, propagation_nested to set.

5>. rolling back rules

When an exception is thrown during a transaction run, the transaction can be declared as rolled back or not rolled back. By default, only runtimeexception will be rolled back and not rolled back when the exception is being inspected.

Of course, you can also change this rollback rule to declare that a transaction can be rolled back when a particular inspected exception occurs. You can also declare that a transaction does not roll back when a particular non-inspected exception occurs.

Understanding of the IOC and transaction manager