Annotations Configuration SSH

Annotations

<?xml version= "1.0" encoding= "UTF-8"?
><beans xmlns= "Http://www.springframework.org/schema/beans" xmlns:aop= "http://www.springframework.org/ Schema/aop "xmlns:tx=" Http://www.springframework.org/schema/tx "xmlns:xsi=" http://www.w3.org/2001/ Xmlschema-instance "xmlns:p=" http://www.springframework.org/schema/p "xmlns:context="/HTTP/ Www.springframework.org/schema/context "xsi:schemalocation=" Http://www.springframework.org/schema/beans/http WWW.SPRINGFRAMEWORK.ORG/SCHEMA/BEANS/SPRING-BEANS-2.5.XSDHTTP://WWW.SPRINGFRAMEWORK.ORG/SCHEMA/AOP/HTTP Www.springframework.org/schema/aop/spring-aop-2.5.xsd HTTP://WWW.SPRINGFRAMEWORK.ORG/SCHEMA/TX/HTTP Www.springframework.org/schema/tx/spring-tx-2.5.xsd Http://www.springframework.org/schema/context/HTTP Www.springframework.org/schema/context/spring-context-2.5.xsd "><!--read the properties configuration file--><beanclass=" Org.springframework.beans.factory.config.PreferencesPlaceholderConfigurer "><property name=" Locations "> <list>< location of the!--configuration file--><value>classpath:jdbc.properties</value></list></property></bean><!--Configuring the data source--><bean id= " DataSource "destroy-method=" Close "class=" Com.mchange.v2.c3p0.ComboPooledDataSource "><property name=" Driverclass "value=" Oracle.jdbc.driver.OracleDriver "/><property name=" Jdbcurl "value=" ${jdbcurl} "/>< Property name= "User" value= "${user}"/><property name= "password" value= "${password}"/><property name= " Maxpoolsize "value=" "/><property name=" Minpoolsize "value=" 1 "/><property name=" initialPoolSize "value = "1"/><!--the maximum spare time of the connection--><property name= "MaxIdleTime" value= "/><"!-- When the connection pool is exhausted, the client calls getconnection () to wait for the new connection, and after the timeout, the SQLException is thrown and, if set to 0, waits indefinitely. Unit milliseconds. default:0--><property name= "Checkouttimeout" value= "$"/></bean><!--configuration Sessionfactory- <bean id= "Sessionfatory" class= "Org.springframework.orm.hibernate4.LocalSessionFactoryBean" ><property Name= "DataSource" ref= "DataSource" ></propErty><property name= "hibernateproperties" ><props><!--sessionfactory.getcurrentsession () Can complete a series of work, when called, Hibernate binds the session to the current thread. After the transaction has ended. Hibernate frees the session from the current thread. and close the session. When Getcurrentsession () is called again. Will get a new session--><prop key= "Current_session_context_class" >thread</prop><prop key= " Hibernate.dialect ">org.hibernate.dialect.MySQL5InnoDBDialect</prop><!--take the initiative to re-connect--><prop key=" Hibernate.autoreconnect ">true</prop><!--Display SQL statements--><prop key=" Hibernate.show_sql ">true</ prop><!--Link Encoding method--><prop key= "hibernate.connection.characterEncoding" >utf-8</prop><!-- Secondary cache--><prop key= "Hibernate.cache.use_second_level_cache" >true</prop><!--3 to specify the vendor of the cache-->< !--<prop key= "Hibernate.cache.provider_class" >org.hibernate.cache.ehcache.ehcacheregionfactory</prop >--><prop key= "Hibernate.cache.region.factory_class" > Org.hibernate.cache.ehcache.ehcacheregionfactory</prop><!--Verify--><prop key= "Javax.persistence.validation.mode" >none</prop><!--Create the table yourself-- ><!--<prop key= "Hibernate.hbm2ddl.auto" >update</prop>--></props></property> <!--the location of the ORM mapping file three--><!--mappingdirectorylocations: Specifies the mapped file path--><property name= " Mappingdirectorylocations "><list><value>classpath:cn/jbit/bean</value></list></ property><! [cdata[< a--><!--the location of the ORM mapping file!--mappingresources: Specify classpath under detail map file name--><property name= " Mappingresources "><list><value>cn/jbit/bean/dept.hbm.xml</value></list></ property><!--The location of the ORM mapping file--><!--mappinglocations: Able to specify whatever file path, and can specify prefix: classpath, file, etc.--><!- -can also be specified with a wildcard character. ' * ' specifies a file (path) name. ' * * ' specifies multiple file (path) names, such as:--><property name= "Mappinglocations" ><list><value>classpath:cn/jbit/ bean/*.hbm.xml</value></list></property><!--The location of the ORM mapping file!--three--><Mappingdirectorylocations: Specifies the mapped file path--><property name= "Mappingdirectorylocations" ><list><value >classpath:cn/jbit/bean</value></list></property><!--Annotation Scan class--><property name= " Annotatedclasses "><list><value></value></list></property><!--Annotation Scan Package-- <property name= "Annotatedpackages" &GT;&LT;LIST&GT;&LT;VALUE&GT;&LT;/VALUE&GT;&LT;/LIST&GT;&LT;/PROPERTY&GT;] ]></bean><!--declaring transaction manager--><bean id= "TransactionManager" class= " Org.springframework.orm.hibernate4.HibernateTransactionManager "><property name=" sessionfactory "ref=" Sessionfactory "/></bean><!--Configuring things Management--><! [cdata[transaction management is an indispensable technology in enterprise application development to ensure data integrity and consistency. A transaction is a series of actions that are treated as a separate unit of work. These actions are either complete or all four key properties (ACID) atomicity that do not work on the transaction ( atomicity): A transaction is an atomic operation that consists of a series of actions. The atomicity of the transaction ensures that the action is either complete or completely ineffective. Conformance (consistency): Once all the transactions have completed, the transaction is committed. Data and resources are in a consistent state that satisfies business rules. Isolation (Isolation): There may be many transactions that deal with the same data at the same time, so everything should be isolated from other transactions to prevent data corruption. Persistence (DurabiliTY): Once the transaction is complete, no matter what system error occurs, its results should not be affected. Typically, the result of a transaction is written to persistent memory. Transaction management in spring as an enterprise application framework, spring defines an abstraction layer on top of different transaction management APIs. Instead of having to understand the underlying transaction management API, application developers can use Spring's transaction management mechanism. Spring supports both programmatic transaction management and declarative transaction management. Programmatic transaction management: Embed transaction management code into business methods to control the commit and rollback of transactions. When you programmatically manage transactions, you must include additional transaction management code in each transaction operation. Declarative transaction management: In most cases, it is better than programmatic transaction management. It separates the transaction management code from the business method and implements the transaction management in a declarative manner. Transaction management, as a crosscutting concern, can be modularized by means of an AOP approach. Spring supports declarative transaction management through the Spring AOP framework. Spring abstracts a set of transactional mechanisms from different transaction management APIs. Developers can take advantage of these transactional mechanisms without having to understand the underlying transaction APIs. With these transactional mechanisms, transaction management code can be independent of specific transactional technologies. Spring's core transaction management abstraction is Org.springframework.transaction.PlatformTransactionManagerorg.springframework.orm.hi Bernate4. Hibernatetransactionmanager an implementation of the database transaction manager is accessed using the Hibernate framework]]><!--opening the annotation transaction--><tx:annotation-driven Transaction-manager= "TransactionManager"/><! [Cdata[spring also agreed to simply annotate the transaction method with @Transactional annotations. In order to define a method to support transactional processing, you can add @Transactional annotations to the method. Based on the Spring AOP agent mechanism, only the public side can be labeled The ability to add @Transactional annotations at the method or class level. When this annotation is applied to a class, all public methods in the class are defined to support transactional processing. Only need to be enabled in the Bean configuration file<tx:annotation-driven> element and specify the transaction manager for it to be able. Assuming the name of the transaction processor is TransactionManager, you can omit the Transaction-manager attribute from the <tx:annotation-driven> element. This element will proactively detect the transaction handler for that name. Transactional propagation properties When a transaction method is also called by a transactional method, you must specify how the transaction should propagate.  For example, a method might continue to execute in an existing transaction, or it might open a new transaction and execute it in its own transaction. REQUIRED: The business method needs to be executed in a container.
Assuming the method executes, it is already in a transaction, so join the transaction, or create a new transaction yourself.
Not_supported: Declaring a method does not require a transaction. If the method is not associated to a transaction, the container does not open the transaction for him. Suppose that the method is called in a transaction.       The transaction is suspended and the original transaction resumes execution after the call is finished. RequiresNew: Regardless of whether there is a transaction, the method will initiate a new transaction for itself. Suppose that the method has been executed in a transaction.       The original transaction is suspended and the new transaction is created. MANDATORY: The method can only be executed in an existing transaction, and the business method cannot initiate its own transaction. Assumed to be called in an environment without transactions.       Container throws an exception. SUPPORTS: The method is called within the scope of a transaction. The method becomes part of the transaction. Assuming that the method is called outside the scope of the transaction, the method executes in an environment without transactions.
Never: This method must never be executed within the scope of a transaction.
Assume that the exception is thrown.      Only this method is not associated to any transaction and is executed normally. NESTED: Assuming that an active transaction exists, it is executed in a nested transaction. Assume there are no active transactions. Then press the required property to execute. It uses a separate transaction. This transaction has multiple savepoint that can be rolled back.
The rollback of internal transactions does not affect external transactions. It only works with the Datasourcetransactionmanager transaction manager.
The isolation level of a transaction in theory, transactions should be completely isolated from one another in order to avoid the problems caused by a concurrent transaction. However, that can have a significant impact on performance, because transactions must be executed sequentially. In real-world development, transactions are performed at a lower isolation level in order to improve performance. The isolation level of a transaction enables you to specify the transaction isolation level that Spring supports by isolating transaction properties The default isolation level for the database is used by default, and for most databases, the isolation level is Read_ Commited Read_uncommited agrees that the transaction reads the changes that have been committed by other transactions, dirty reads, non-repetition, and phantom-read problems will appear read_commited just agree that the transaction reads the changes that have been committed by other transactions, to avoid dirty reads, But the problem of non-repetition and phantom reading can still occur repeatable_read such a transaction isolation level prevents dirty reads and cannot be read repeatedly. However, Phantom reads may occur.
SERIALIZABLE This is the most reliable transaction isolation level at the highest cost.
Transactions are processed for sequential execution. In addition to preventing dirty reads. Not repeated reading, but also to avoid the Phantom read Dirty Read, not repeated reading, Phantom read Dirty read: Zhang San salary is 5000, transaction a in his salary changed to 8000, but transaction a has not yet been submitted. At the same time. Transaction B is reading Zhang San's salary and reading to Zhang San's salary is 8000.
Then, transaction A has an exception, and the transaction is rolled back. Zhang San's wages were rolled back to 5000. Finally, the data that transaction B reads to a Zhang San salary of 8000 is dirty data.    Transaction B did a dirty reading. Do not read repeatedly: in transaction A. Read to Zhang San the salary is 5000, the operation is not complete, the transaction has not been submitted. At the same time, transaction B changed the salary of Zhang San to 8000 and submitted the transaction.
Then, in transaction A, read Zhang San's wages again. At this point the salary becomes 8000. The result of reading back and forth two times in a transaction is not.     resulting in non-repeatable reading. Phantom Reading: A now employs 10 people with a salary of 5000. Transaction a reads all employees with a salary of 5000 to 10 people. At this time Transaction B Inserts a record with a salary of 5000. This is, transaction a reads the employee with a payroll of 5000 again, and records 11 people.     This creates a phantom read. Set ROLLBACK TRANSACTION properties by default, only unchecked exceptions (RuntimeException and error type exceptions) cause the transaction to be rolled back. The check exception does not. The rollback rules for a transaction can be defined by the Rollbackfor and Norollbackfor properties of the @Transactional annotations. These two properties are declared as class[] types, so you can specify more than one exception class for both properties. Rollbackfor: You must roll back norollbackfor when you encounter: a set of exception classes. You must not roll back timeouts and read-only properties when they are encountered because transactions can acquire locks on rows and tables, long transactions consume resources and have an impact on overall performance. The database engine optimizes this transaction by assuming that a thing simply reads the data but does not make changes. Timeout Transaction Property Timeout: How long a transaction can persist before it is forced to roll back. This prevents long-running transactions from consuming resources. Read-Only Transaction property ReadOnly: Indicates that the transaction only reads the data but does not update the data, which helps the database engine to optimize the transaction.] ></beans>

Annotations Configuration SSH