CURD taken programmer (a) database transactions

　　Take the first step, from passive to active.

This paper records: the four transaction properties; transaction isolation level; 7 kinds of spring transaction propagation properties; transaction spring arrangement (programmatic, declarative)

Four characteristics of the transaction (ACID)
1. Atomicity (Atomicity)
  integral, all the operations which either all succeed or all fail.
2. Consistency (Consistency)
  Consistency of data visibility constraint is to ensure that the data in the intermediate state of multiple operations in a transaction is not visible to other transactions. Look online to find a lot of explaining relatively easy to understand example of transfer: a transaction which includes a person money increases, another reduction in the transaction in two operations have intermediate states a person another person also cut money did not add money to the intermediate state, refers to the consistency of this intermediate state at this time other things are calling this table will not see such a state, it must be not only see the initial transfer of state money and turn finished status.
3. Isolation (Isolation)
  isolation is when a plurality of users concurrent access to the database, such as operating with a table, a database for each user transaction open, operation not being disturbed by other transactions, the plurality of concurrent transactions to each other isolation. Derived from the isolation level
4. Persistence (durability)
  Once the transaction is submitted, then the changed data in the database is permanent, will not be lost even if the transaction commit operation is encountered in the case of a database system failure.
  tips: atomicity and consistency of the different emphases: atomic concerned state, either all succeed, or all fail, partially successful state does not exist. The visibility of the consistency of the data of interest, intermediate state data is not visible to the outside, only the initial data state and final state of the external visible
Transaction isolation level
　　four kinds of questions:
1. Two transactions simultaneously update a data (lost update)
2. An update uncommitted transaction is complete, the data is rolled back, read a read transaction reads dirty data will be updated. (Dirty read)
3. When the same query is executed twice or more the same transaction, each time to get different data. Usually because another concurrent transactions have been updated during the two inquiries (non-repeatable read)
4. The first transaction reads some of the data, then the second transaction inserts new data in the table, this is the first transaction will then read the same data multiple lines (phantom read)

　　　　　　The four isolation levels:

1. Read Uncommitted (Uncommitted read content)
  allows a transaction to read other transactions submitted has not been altered. Dirty reads, non-repeatable read, phantom read may occur
2. Read Committed (read submission)
  only allows transactions to read changes have been submitted to other matters, to avoid dirty reads, but non-repeatable read and phantom read problems may still arise
3. Repeatable Read (can be re-read)
  
  Ensure that the transaction can be read many times the same value from a field. The duration of the transaction, other transactions prohibited on this field to be updated, to avoid dirty reads and non-repeatable read, phantom read but problems remain
4. Serializable (serializable)
  ensure that the transaction can read the same row from a table, the duration of the transaction, other prohibited transaction execution the table insert, update, delete. All concurrency problems can be avoided, but lower performance.

The propagation properties of spring Affairs

Propagation.REQUIRED (required): support for the current transaction, if the transaction currently have, then adding the transaction, if the transaction is not currently create a new (active players, mutual influence rollback)
Propagation.NOT_SUPPORTED (NOT_SUPPORTED): carried out in a non-transactional way operation, if the current put the current transaction pending transaction exists, after the implementation of the recovery Affairs (surface set back the original transaction was executed normally);
Propagation.SUPPORTS (the Supports): If you currently have a transaction is added, if not then do not affairs. (Go with the flow, no no there there, active players)
Propagation.MANDATORY (mandatory): Only way to support the implementation of the transaction, if the transaction is not currently an exception is thrown. (Strongly support the leadership decision-making)
PROPAGATION_NEVER (Never): support only non-transactional execution mode, if the current transaction exists, an exception is thrown. (Naysayers)
Propagation.REQUIRES_NEW (REQUIRES_NEW): support current affairs, current affairs there, then suspends the current transaction to create a new transaction if no transaction is a transaction that you create. (Independent, independently of each other)
Propagation.NESTED (nested nested transactions): If the current transaction exists, it is embedded in the current transaction. If no transaction, a new transaction own execution (and as required). Nested transactions using the rollback to save point as the point when the internal affairs of rollback will not affect the submission of external things; but go back with the rollback will roll back the external internal affairs. (Proactive player, do not bother other people, but people will bother you)

Note: The transaction must be valid in the same thread,
Transaction spring arrangement (programmatic, declarative)
programming the formula : or a method for packaging low-level API calls provided by the system in the program, is not in contact ultimately persistence framework code.

Declarative (primarily) :
Step 1: Configure transaction manager in spring configuration

Step Two: In front of the need to use the transaction methods with the @Transactional annotation
example:


<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory">
<ref bean="mySessionFactory"/>
</property>


<tx:advice id="TestAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="save*" propagation="REQUIRED"/>
<tx:method name="del*" propagation="REQUIRED"/>
<tx:method name="update*" propagation="REQUIRED"/>
<tx:method name="add*" propagation="REQUIRED"/>
<tx:method name="find*" propagation="REQUIRED"/>
<tx:method name="get*" propagation="REQUIRED"/>
<tx:method name="apply*" propagation="REQUIRED"/>
</tx:attributes>
</tx:advice>
<!- participating in a transaction class configuration -> <AOP: the pointcut ID = "allTestServiceMethod" = expression The "Execution (com.test.testAda.test.model.service * * * (..)..) "/>
<AOP: config>

<AOP: Advisor-REF = the pointcut "allTestServiceMethod" the advice-REF = "TestAdvice" />
</ AOP: config>
caveats:

(1) advice (recommendation) name: Since each module will have its own Advice, therefore need to be made in the naming specification, preliminary idea is the module name + Advice (just a naming convention).

(2) tx: attribute tag is configured as a method of the type named transaction.

         如<tx:method name="save*" propagation="REQUIRED"/>

        Where * is a wildcard, which represents all the ways to save as the beginning of implies conformity to this method of naming as a transaction.

        propagation = "REQUIRED" representatives supported the current transaction, if no transaction, we create a new business. This is the most common choice.

(3) aop: pointcut configuration class tag participating in the transaction, since the database is operational in the Service, the ligand should contain Service class as those of the transaction.

       First, it should be particularly noted that the id name, the same as each module has its own affairs section, so I think the initial naming convention because all + module name + ServiceMethod. And different between each module also lies in the following one:

       expression="execution(* com.test.testAda.test.model.service.*.*(..))"

       Wherein * represents a return to the first value, the second lower sub-packet service representatives *, * represents the third method name, "(..)" represents method parameters.

(4) aop: advisor top label is to manage our affairs configured as a two-part property integrate the whole transaction management.

Graphic:

CURD taken programmer (a) database transactions

Guess you like