First, what is a business? A transaction (Transaction) is a series of operations performed as a single logical unit of work. These actions are submitted to the system as a whole, either executed or not executed. A transaction is an inseparable unit of work logic
Transfer Operation A->b:
BEGIN TRANSACTION
1. Update the balance of account a
2. Record the transaction log of account a
3. Update the balance of account B
4. Log the transaction log of account B
End transaction
Ii. Characteristics of the transaction (ACID) atomicity atomicity
The transaction must be an atomic unit of work. For their data modifications, they are either fully executed or not executed.
Conformance consistency
When a transaction is complete, you must keep all data in a consistent state. In a related database, all rules must be applied to transaction modifications to maintain the integrity of all data. At the end of the transaction, all internal data structures must be correct. The integrity constraints of the database are not compromised until the transaction begins and after the transaction has ended.
Isolation isolation
Modifications made by a concurrent transaction must be isolated from modifications made by any other concurrent transaction. The state in which the data is located when the transaction is viewing the data, either when another concurrent transaction modifies its state or after another transaction modifies it, and the transaction does not view the data in the middle state.
Persistent durability
After the transaction is complete, its effect on the system is permanent: the changes made to the database by the firm are persisted in the database and are not rolled back.
III. Transaction management policy Container management transaction (CMT Container Manage Transaction)
Bean Management Transaction (BMT Bean Manage Transaction)
Jta:java Transaction API
1.JTA is a series of interfaces that Java EE provides to manage distributed transactions, which provides a communication mechanism between TransactionManager and ResourceManager.
A.javax.transaction.usertransaction provides an interface that is directly used by application code to define transaction boundaries and get transaction state.
B.javax.transaction.transactionmanager interfaces that are primarily used by application servers, in addition to defining transaction boundaries and getting transaction state, can also suspend (suspend) or restart (resume) transactions.
Iv. Transaction attribute required:
The method call requires a transaction context, and if a transaction context already exists, then this is used, and if it does not exist, a new transaction is created if no new transaction exists, and if there is a transaction, the bean uses the transaction.
RequiresNew:
The container creates a new transaction before each method call on the bean and commits the transaction before returning. When a bean method is called, a new transaction is always started. If the transaction already exists, the transaction is suspended until the new transaction is complete.
NotSupported:
The bean runs outside the transaction context. During a method call, an existing transaction is suspended. You cannot invoke a bean inside a transaction. Hangs an existing transaction until the method that is called in the bean completes.
Supports:
If there is a transaction context, the method call uses the current transaction context. If it does not exist, a new transaction context is not created. The container does not start a new transaction. If the transaction already exists, the bean is included in the transaction.
Note: With this property, the bean can run without a transaction.
Mandatory:
A transaction context is required for the method invocation. Throws an exception if it does not exist. An active transaction must already exist. If no transaction exists, the Javax.ejb.TransactionRequiredException is thrown.
Never:
The method invocation requires that no transaction context exists. Throws an exception if it is present. The bean must always run concurrently with different transactions. Throws a java.rmi.RemoteException if there is a transaction.
Transaction Properties-Transactional propagation
V. TRANSACTION ISOLATION LEVEL Objective: In the database operation, in order to effectively guarantee the correctness of the concurrent read data, the proposed transaction isolation level.
Problem:
Update missing (Lost update)
Two transactions update a row of data at the same time, but the second transaction fails to exit, resulting in two modifications to the data that are invalidated. This is because the system does not perform any lock operations, so concurrent transactions are not isolated.
Dirty Read (Dirty Reads)
A transaction begins reading a row of data, but another transaction has updated the data but failed to commit it in time. This is quite dangerous because it is possible that all operations are rolled back.
Non-repeatable read (non-repeatable Reads)
A transaction repeatedly reads the same row of data two times, but gets different results. It includes the following situations:
(1) After the transaction T1 reads a data, the transaction T2 modifies it, and when the transaction T1 reads the data again, it gets a different value than the previous one.
(2) Phantom reading (Phantom Reads): The transaction is in the process of two queries, the results of the second query contains data that did not appear in the first query or missing data from the first query (this does not require two queries of the same SQL statement). This is due to the fact that another transaction was inserted into the data during the two queries.
Read isolation_read_uncommited not authorized
Dirty reads are allowed, but updates are not allowed to be lost. If a transaction has already started writing data, the other data does not allow simultaneous writes, but allows other transactions to read the data on this line. This isolation level can be achieved through an "exclusive write lock".
Authorization to read isolation_read_committed
Allow non-repeatable reads, but dirty reads are not allowed. This can be achieved through "instantaneous shared read lock" and "exclusive write lock". Transactions that read data allow other transactions to continue to access the row's data, but uncommitted write transactions will prevent other transactions from accessing the row.
REPEATABLE Read Isolation_repeatable_read
Non-repeatable reads and dirty reads are prohibited, but phantom data can sometimes occur. This can be achieved through "shared read lock" and "exclusive write lock". Transactions that read data prohibit write transactions (but allow read transactions), and write transactions prohibit any other transactions.
Serialization of Isolation_serializable
This constant indicates dirty reads, non-repeatable reads, and false reads are forbidden.
This level includes things that are blocked in transaction_repeatable_read, and prevents a transaction from reading all of the row records while satisfying the Where condition, and the second transaction inserts a row under the Where condition, and then the previous transaction reads repeatedly under the same conditions, This is a record of what is not true for the row.
Isolation_default (Spring)
The default isolation level is related to the specific database, which is the default isolation level for the specific database, and different databases are not the same
Transaction Isolation Policy
Weblogic:
Weblogic-ejb-jar.xml
...
<transaction-isolation>
<isolation-level>TransactionSerializable</isolation-level>
<method>
<ejb-name>TradingService</ejb-name>
<method-inf>Remote</method-inf>
<method-name>placeTrade</method-name>
</method>
</transaction-isolation>
Spring:
...
<bean id= "Tradingservice" class= "Org.springframework.transaction.interceptor. Transactionproxyfactorybean ">
<property name= "TransactionManager" ><ref bean= "TransactionManager"/></property>
<property name= "target" ><ref local= "Tradingservice Target"/></property>
<property name= "Transactionattributes" >
<props>
<prop key= "insert*" >PROPAGATION_REQUIRED,ISOLATION_SERIALIZABLE</prop>
</props>
</property>
</bean>
VI. transaction type Local transaction model: locally Transaction model
Program Custom Transaction Model: Programmatic Transaction Models
Statement-based transaction model: declarative Transaction Models
Vii. distributed transactions Multiple data sources
Two-paragraph submission agreement
In the first step, the transaction controller asks each resource manager if it is ready to commit;
In the second step, if all the resource managers are ready to commit, the transaction manager requires all commits.
Spring Transaction Processing
1. Declarative transaction Management
2. Programmatic Transaction Management
Spring declarative transactions do not provide transactional context propagation across remote calls provided by high-end application servers. If you need these features, we recommend that you use EJBS. However, do not use these features easily. Because normally we don't want transactions to span remote calls.
Transaction processing in spring-statement-type transaction management
Transaction properties
Propagation_required
Propagation_supports
Propagation_mandatory
Propagation_requires_new
propagation_not_supported
Propagation_never
propagation_nested If an active transaction exists, it is run in a nested transaction. If there is no active transaction, it is performed by the Transactiondefinition.propagation_required property. Nested transactions A very important concept is that the inner transaction relies on the outer layer. When the outer transaction fails, the actions of the inner layer are rolled back. The failure of the inner transaction operation does not cause the rollback of the outer transaction
Isolation Isolation Level
Read-only is read-only and defaults to False
Most spring users choose declarative transaction Management. This is a choice that has the least impact on application code and is therefore best aligned with the idea of a non-intrusive lightweight container.
Java
The service class and we want to make transactional
@Transactional
public class Defaultfooservice implements Fooservice {
Foo Getfoo (String fooname);
Foo Getfoo (String fooname, string barname);
void Insertfoo (foo foo);
void Updatefoo (foo foo);
}
Xml
<tx:annotation-driven transaction-manager= "Txmanager"/>
<!--a platformtransactionmanager is still required-
<bean id= "Txmanager" class= "Org.springframework.jdbc.datasource.DataSourceTransactionManager" >
<!--(this dependency is defined somewhere else)-
<property name= "DataSource" ref= "DataSource"/>
</bean>
Transaction processing in spring-programmatic transaction management
Using Transactiontemplate (recommended)
Directly using a Platformtransactionmanager implementation
Using Transactiontemplate
Private final transactiontemplate transactiontemplate;
Use Constructor-injection to supply the Platformtransactionmanager
Public SimpleService (Platformtransactionmanager transactionmanager) {assert.notnull (TransactionManager, "the ' TransactionManager ' argument must not being null. ");
This.transactiontemplate = new Transactiontemplate (TransactionManager);
The transaction settings can is set here explicitly if so desired this.transactionTemplate.setIsolationLevel (transactio ndefinition.isolation_read_uncommitted); Set TRANSACTION ISOLATION LEVEL
This.transactionTemplate.setTimeout (30); Transaction timeout
}
...
Transactiontemplate.execute (New Transactioncallbackwithoutresult () {
protected void Dointransactionwithoutresult (Transactionstatus status) {
try {
UpdateOperation1 ();
UpdateOperation2 ();
} catch (Somebusinessexeption ex) {
Status.setrollbackonly (); Rolling back
}
}
});
Using Platformtransactionmanager
Defaulttransactiondefinition def = new Defaulttransactiondefinition ();
Explicitly setting the transaction name is something, can only be done programmatically
Def.setname ("Sometxname"); Def.setpropagationbehavior (transactiondefinition.propagation_required);
Transactionstatus status = Txmanager.gettransaction (Def);
try {
Execute your business logic here
} catch (MyException ex) {
Txmanager.rollback (status);
Throw ex;
}
Txmanager.commit (status);
<bean id= "Txmanager" class= "Org.springframework.jdbc.datasource.DataSourceTransactionManager" > <property Name= "DataSource" ref= "DataSource"/> </bean>
Java EE transaction
