SSH annotation configuration, bean annotation, and transaction Annotation

Anyone who has used SSH annotations knows that to use annotations, you must enable annotation configuration in the applicationcontext. xml configuration file as follows:
1. the header Declaration must be added
Xmlns: context = "http://www.springframework.org/schema/context"
Http://www.springframework.org/schema/context
Http://www.springframework.org/schema/context/spring-context-3.0.xsd

2. File internal configuration
<Context: annotation-config/> <! -- Enable the annotation mode -->
<Context: component-scan base-package = "com. Newer"/> <! -- Enable automatic bean scanning, which is generally configured with the basic package. If this option is used, do not configure-enable annotation mode -->

Bean annotation Management
Spring automatically scans and manages bean annotations in four configuration modes:
@ Service for service example: @ Service ("baseservice ")
@ Controller for the control layer (Action) Example: @ controller ("baseaction ")
@ Repository for data access layer (DAO) Example: @ repository ("basedao ")
@ Component generic configuration (used when the component is not sure), the above three configurations are based on this extension
We recommend that you use the corresponding configuration for different layers. Do not use @ component for all configurations.

 

Spring transaction annotation Configuration
<! -- XML, @ transaction configuration -->
<Bean id = "hibernatetransaction" class = "org. springframework. Orm. hibernate3.hibernatetransactionmanager">
<Property name = "sessionfactory">
<Ref bean = "sessionfactory"/>
</Property>
</Bean>
<TX: annotation-driven transaction-Manager = "hibernatetransaction" proxy-target-class = "true"/>

@ Transactional // default transaction Configuration
@ Transactional (rollbackfor = Exception. Class) // roll back when an exception occurs
@ Transactional (norollbackfor = Exception. Class) // do not roll back if an exception occurs.
@ Transactional (readonly = true) // read-only, performance optimized, High Efficiency
@ Transactional (propagation = propagation. not_supported) // do not enable transaction
@ Transactional (propagation = propagation. Required) // if a transaction exists, add it to the transaction. If no transaction exists, create a new one (if not written)
@ Transactional (propagation = propagation. not_supported) // The container does not enable transactions for this method.
@ Transactional (propagation = propagation. requires_new) // creates a new transaction regardless of whether a transaction exists. The original transaction is suspended, the new transaction is completed, and the old transaction continues to be executed.
@ Transactional (propagation = propagation. Mandatory) // It must be executed in an existing transaction; otherwise, an exception is thrown.
@ Transactional (propagation = propagation. Never) // It must be executed in a non-existing transaction; otherwise, an exception is thrown (opposite to propagation. Mandatory)
@ Transactional (propagation = propagation. supports) // if other beans call this method and declare transactions in other beans, use transactions. if other beans do not declare transactions, no transactions are required.
@ Transactional (propagation = propagation. nested)
@ Transactional (propagation = propagation. required, readonly = true) // readonly = true read-only, cannot be updated, delete
@ Transactional (propagation = propagation. required, timeout = 30) // set the timeout value.
@ Transactional (propagation = propagation. required, isolation = isolation. Default) // sets the database isolation level

Annotation objects can be inherited by dependent classes. For example, if a service inherits baseservice, it also inherits the things declaration of baseservice.
You can configure the attributes of different things based on different needs. Below are common things isolation levels and propagation attributes:

1. transaction isolation level

 

Default	Default database isolation level
Read_uncommitted	Read uncommitted data (dirty reads, non-repeated reads, Phantom reads, avoiding first-class loss of updates)
Read_committed	Read committed data (non-repeated, phantom read will occur)
Repeatable_read	Repeatable read (phantom read will occur)
Serializable	Serializing

 

 

 

 

 

 

 

 

2. propagation attributes of transactions

 

Required	Transaction required, exist: Join, not exist: create by yourself. This is the default Propagation Behavior of spring.
Supports	Support transactions, exist: Join, do not exist: Do not use transactions
Mandatory	Only one existing transaction can be executed, and the business method cannot initiate its own transaction. If the business method is called in a non-transaction environment, an exception is thrown.
Requires_new	The business method always initiates a new transaction for itself. If the method is already running in a transaction, the original transaction is suspended, and the new transaction is created until the method ends, the new transaction ends, and the original transaction will resume execution.
Not_supported	A transaction is required to declare a method. If the method is not associated with a transaction, the container will not start the transaction for it. if a method is called in a transaction, the transaction will be suspended. After the method call is completed, the original transaction will resume execution.
Propagation_never	The declarative method cannot be executed within the transaction scope. If the method is executed within a transaction range, the container throws an exception. It can be executed normally only when the method is not associated with the transaction.
Nested	Nested transactions (not supported by general databases)

 

 

 

 

 

 

 

 

 

 

 

 

 

Action annotation Singleton Problem
With Spring management, action is the singleton mode by default. However, you cannot use a single example for all projects. To use this example, you need to add related annotations to switch to a non-singleton:
Configure @ scope ("prototype") on the action, and each request will have a new instance.

 

Bean initialization execution configuration (executed when the server is started)
If you want to execute a method during bean initialization, you can use the annotation @ postconstruct. Similarly, initialization ends. @ predestroy
@ Postconstruct
Public void Init (){
System. Out. println ("initialization execution method ");
}

@ Predestroy
Public void destory (){
System. Out. println ("close resource ");
}

We recommend that you use the singleton mode. If Bean class configuration @ scope ("prototype"), the Bean class will be initialized only when the Bean class is called,
The init method can only be executed when the bean is called.
Turn, initialization execution details, and xml configuration Introduction: http://blog.csdn.net/ypl9935250/article/details/7013231