Comprehensive Analysis of EJB programmatic Transaction Management (BMT) and clear Transaction Management (CMT) (I)-basic concepts of transactions

I. ACID properties of database transactions

 

Atomicity

(Atomic) (Atomicity)

A transaction must be an atomic unit of work. modifications to its data must either be performed in all or not. Generally, operations associated with a transaction share a common goal and are mutually dependent. If the system executes only one subset of these operations, the overall goal of the transaction may be broken. Atomicity eliminates the possibility of a subset of system processing operations.

Consistency

(Consistent) (consistency)

When the transaction is completed, all data must be consistent. In related databases, 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 (such as B-tree indexes or two-way linked lists) must be correct. Some maintenance consistency responsibilities are borne by application developers who must ensure that the application has enforced all known integrity constraints. For example, when developing an application for transfer, do not move any decimal point during transfer.

Isolation

(Insulation) (isolation)

Modifications made by a concurrent firm must be isolated from those made by any other concurrent firm. The status of the data when the transaction is viewing the data is either the status before the transaction is modified or the status after the transaction is modified. The transaction does not view the data in the intermediate status. This is called serializability because it can reload the starting data and replays a series of transactions so that the State at the end of the data is the same as that of the original transaction execution. When a transaction is serializable, the highest isolation level is obtained. At this level, the results obtained from a group of parallel transactions are the same as those obtained by running each firm consecutively. Since high isolation limits the number of transactions that can be executed in parallel, some applications reduce the isolation level in exchange for greater throughput. Prevent data loss

Durability

(Duration) (durability)

After the transaction is completed, its impact on the system is permanent. This modification will remain even if a fatal system failure occurs.

 

Ii. transaction isolation level

■ Read uncommitted:

This level is not safe, and the query in the transaction will read the data that is currently being set for other transactions that have not yet been committed.

 

■ Read committed:

This level is relatively safe, and all the data read in the transaction is committed. However, if you read the same record twice, however, when another transaction changes the record and successfully commits the record during the two read operations, the data of the same record is inconsistent between the two read operations in the same transaction. This situation rarely occurs, because generally, the program of the same transaction will not read the same record repeatedly. If Hibernate is used, it will be safer, hibernate's level-1 cache does not allow the program to read the same record twice to the database.

 

■ Repeatable read:

This level solves the problem of different data reading results for the same transaction. This level is also the default transaction level (such as MySQL) of many databases)

 

■ Serializable:

This level will allow all transactions to be serialized and chemical, and each transaction can only be queued for database operations, similar to the single-threaded servlet working mechanism, so that when not a large amount of database access, database operation efficiency will be extremely low and should be avoided

 

Iii. Values of the EJB transaction attributes include:

 

(1) required: If the EJB component must always run in a transaction, use the required mode. If a transaction is already running, the EJB component participates in the transaction. If no transaction is running, the EJB container starts a new transaction for the EJB component.

 

Required is the default and most commonly used transaction property value. This value specifies that the EJB method must be called within the transaction. If you call a method from a non-transactional client, the container starts the transaction before calling the method and ends the transaction when the method returns. On the other hand, if the caller calls a method from the transactional context, the method will join existing transactions. When a transaction is propagated from the client segment, if our method indicates that the transaction should be rolled back, the container not only rolls back the entire transaction, but also throws an exception to the client, so that the client knows that the transaction it started has been rolled back by another method.

 

(2) requires_new: When you call EJB, if you always want to start a new transaction, you should use the requiresnew transaction attribute. If the customer already has a transaction when calling the EJB component, the current transaction is suspended, the container starts a new transaction, and delegates the call request to the EJB component. That is to say, if the client already has a transaction, it will pause the transaction and know the return position of the method. Whether the new transaction is successful or fails will not affect the existing transaction of the client. When the EJB component performs corresponding business operations, the container will commit or roll back the transaction, and the container will restore the original transaction. Of course, if the customer does not have a transaction when calling the EJB component, you do not need to execute the pending or resuming operations of the transaction.

 

The requiresnew transaction attribute is very useful. If the EJB component needs the acid attribute of the transaction and runs the EJB component in a single independent work unit, other external logic is not included in the current transaction, you must use the requirednew transaction attribute. If you need a transaction but do not want the rollback of the transaction to affect the client, you should use it. In addition, this value should also be used when you do not want the client rollback to affect you. Logging is a good example. Even if the parent transaction is rolled back, you want to record the error to the log. On the other hand, failure of logging minor debugging information should not cause rollback of the entire transaction, and the problem should be limited to the logging component.

 

(3) supports: if an EJB component uses the supports transaction attribute, the EJB component runs only when the client that calls it has enabled the transaction. If the customer is not running in the transaction, the EJB build will not run in the transaction. Supports is similar to required transaction attributes. However, required requires that the EJB component must run in the transaction. If the support transaction attribute is used, the EJB formation is very flexible and does not run in the transaction.

 

(4) mandatory: the mandatory transaction attribute requires that the client that calls the EJB component must already be running in the transaction. If the EJB method using the mandatory attribute is called from a non-transactional client, the customer will receive the javax. EJB. ejbtransactionrequiredexception exception thrown by the system. The use of the mandatory transaction attribute by the EJB component is extremely secure, which ensures that the EJB build runs in the transaction. If the client is not running in a transaction, it cannot call the EJB component that applies the mandatory transaction attribute. However, the mandatory transaction attribute requires 3rd
Party (and customer) must start the transaction before calling the EJB component. The EJB container does not automatically start a new transaction for the mandatory transaction attribute, which is the main difference from the support transaction attribute.

 

(5) notsupported: If the EJB component uses the notsupport transaction attribute, it will not participate in the transaction at all. If the caller uses the associated transaction call method, the container will pause the transaction, call the method, and then resume the transaction when the method returns. Generally, this attribute is only used in the automatic validation mode of non-real properties and supports MDB of the JMS provider.

 

(6) Never: If the EJB component uses the never transaction attribute, it cannot participate in the transaction, and if the client that calls it is already in the transaction, the container will change javax. EJB. an ejbexception is thrown to the customer.

 

Transactions. t1 and t2 are two different transactions, T1 is the transaction passed by the customer request, and T2 is the transaction started by the container, understand the important role of various transaction attributes in affecting the transaction length and scope.

Iv. Read-Only attributes of transactions

The read-only attribute of a transaction refers to read-only or read/write operations on transactional resources. Transactional resources are the resources managed by transactions, such as data sources, JMS resources, and custom transactional resources. If you are sure to only perform read-only operations on transactional resources, you can mark the transaction as read-only to improve the transaction processing performance. In transactiondefinition, The boolean type indicates whether the transaction is read-only.

 

V. Transaction rollback rules

Generally, if an unchecked exception (inherited from runtimeexception) is thrown in the transaction, the transaction is rolled back by default. If no exception is thrown or an checked exception is thrown, the transaction is still committed. This is usually the processing method that most developers want and the default Processing Method in EJB. However, we can manually control the transaction to commit the transaction when some unchecked exceptions are thrown, or roll back the transaction when some checked exceptions are thrown.