Basic concepts and vocabulary:
n Transaction Object (or Transaction Component): It is a component involved in transactions. Such as: EJB components, .NET components, CORBA components, etc.
n Transaction Manager: Manage Transaction Objects transaction operations. Just like the command in the band.
N resource: a lasting data source. Such as: Database, Message Queue, etc.
N Resource Manager: Resource managers manage the status of all persistent data. An example of Resource Manager is the driver of database, message queue, or other memory. The most popular Resource Manager interface is the X / Open XA Resource Manager interface. Many database drivers support this interface, XA is actually the industrial standards for Resource Manager.
N ACID (Atomicity, Consistency, Isolation, Durability): A transaction will definitely give four guarantees by the database, they are atomic Atomicity, consistency consistency, Isolation ISOLATION, persistence durability.
Transaction Models. A transaction generally has two models: flat (FLAT) transactions and nested transactions. The current EJB specification only supports flat transactions without supporting nested transactions.
n Flat transaction model: It is to treat a series of operations as an operation. After the transaction begins, the program can make any more operation, which may be a persistent operation. This model is characterized by: If the transaction can end, all operations are persisted, otherwise all operations will not be persisted.
n Necrinking Transaction Model: Embed an atomic transaction operation into other transaction operations. A small transaction block rollback does not cause the entire transaction to roll back. The big transaction block can retry the failed small transaction block. You can imagine the nested transaction model as a tree model, the biggest transaction block is the root of the tree, the small transaction block is the leaves, and the leaf knot rollback does not affect his father's finish.
Transaction in EJB.
n ejbean will be very naturalized, he is a good choice for the strict system.
n In EJB, Transaction will be abstracted, undermate, your code is impossible to interact with Transaction Manager or Resource Manager. The underlying transaction control is abstracted by the container, and your procedure can determine if it is submitted or rolled back.
we must provide some key information to the container, tell him who starts a business, who will submit or roll back, when these steps happen. This is called a "divided transaction boundary". There are three ways to divide a transaction:
1. Programmatic Transaction: The transaction is controlled by the program, and the program is explicitly calling Begin, Commit, Rollback and other methods.
2. Contrarative Transaction: Container intercept program control then automatically calls Begin Start transaction, then return control to bean, then Bean can do any logical business operation, if the program encounters problems, send failed signals to the container The control right is returned to the container after the BEAN is completed. At this time, the container determines whether there is commit or rollback. You can add the following sentence to the deploy descriptor profile to point out the way of using the above control:
3. Client Initiated Transaction: You can control your transactions in the BEAN's client program, such as JSP, servlet, applet, or other EJB. But pay attention to still point in the configuration file to the called Bean is using Programmatic Transaction or the Declarative Transaction.
n Transaction and Entity Bean
l When you call an Entity Bean in the Transaction, the container first calls the EJBLOAD () method in the BEAN to get the data from the database, actually getting a data lock from the database and determines whether the data is consistent with the buffer pool. Then call several business logic methods. After the transaction is submitted, the EJBStore () method is called, and he writes all changes to the database and release the lock.
l Why can the entity bean can use Container-Managed Transaction? Bean-managed transaction can only be used for Session beans or Message-Driven Beans? This is because: For Bean-Managed Transaction, you must explicitly call the begin () or commit () method, you may start the transaction in ejbload () in EJBLOAD () in EJBLOAD (), and submit transactions in EJBStore () . But the problem is that these two methods can only be called by the container, so bean can't determine when these two methods will be called, that is, you start the transaction in the ejbload () method, perhaps this transaction will never be end. The operation of the data can be controlled at will from the session bean and message-driven beans, so there is no such problem.
l Entity Bean does not read and write the database when they are called, but in a transaction. So if your program is written, every function is called, you will start a transaction, then you will read and write a database every time you call these functions! The solution is to let multiple functions in a transaction, in the configuration file, you can configure this.
n Program Control, Container Control, and Client Control These three transaction control methods? Which one should we choose? They have their own advantages:
l Program Control: The advantage is that you can fully control your transaction in your bean. For example, you can run multiple small transactions in a function; but the functions in the Entity Bean of the container control or client control transaction can only be started to start a transaction.
l Container control: The advantage is very simple. You can reduce the amount of code and you can adjust your transaction without changing the code.
l Client Control: Enthere to explain the advantages of this control method. If a remote user does not call an EJB without a client transaction, this EJB has its own transaction control. If the transaction of this bean is completed, the network or server is embarrassed when the results return to the client, which is Java to throw a RMI RemoteException to the client to tell the client network. But such words, the client will not know if the bean is successful. This is the client to write code to know whether the transaction is successful, and these code is very cumbersome and it is easy to erroneously, because the network's failure is possible to always The connection is not connected to the server. The benefit of a client-side transaction is to solve this problem. However, if the client is far from the server side, it is necessary to use this kind of control, because if the distance is too far, it is likely to cause a conflict when the transaction rolls back. N container controlled transactions
l We must provide some transaction attribution to tell the container how to control transactions. You can give each bean different transaction properties. These attributes are defined in the deployment description and you can define properties for the bean to define an attribute for a function in the BEAN. If you define transaction properties to both, the property defined attributes are preferred.
l For Message-Driven Bean, it is recommended to use a container-controlled transaction.
l The following is the interpretation of the transaction attribute value:
u Required: You must use a transaction. If you have a transaction outside this bean, then you join this transaction; otherwise you will start a new transaction.
u Requiresnew: No matter whether there is a transaction in the outside world, start a new transaction.
u Supports: If the outside is already transaction, join this transaction; otherwise, no new transactions will not start.
u Mandatory: Specifies that a transaction must have been launched when the function is called, otherwise TransactionRequiredException will be thrown.
u NotSupported: Bean is not controlled by transaction. If a transaction has been launched before calling bean, this transaction will be temporarily suspended until the transaction will continue after the bean ends.
u Never: bean can't enter the transaction, if you call this bean in a transaction, you will throw ROMOTEEXCEPTION.
l Note: Different types of beans do not necessarily support all of the above types of properties. If: Entiry Bean and Stateful SessionBean with Sessionsynization do not support Never, NotSupported, Supports properties; Message-Driven Bean does not support Never, Supports, RequiresNew, Mandatory properties.
N ejb program controlled transaction
l Program control is more flexible than the container controlled transaction, but it is more cumbersome. And you must use Java Transaction API (JTA).
l Object Management Group (OMG) Organization Defines a standard Object Transaction Service (OTS) has made a lot of work in the bottom of the transaction, making our code more simple, and do not care about the underlying operation.
lun Company divides OTS into two pieces in Java language: Java Transaction Service (JTS) and Java Transaction API (JTA). Where JTS is used by the system-level manufacturer, it helps us have done a lot of complex work; while users can use JTA. l JTA is divided into two sets of interfaces: a set of X / Open XA Resource Manager uses; a group is used by the user. The user mainly uses the Javax.Transaction.UserTransaction interface.
l UsertransAction interfaces with six ways: Being (), Commit (), Rollback (), getStatus (), setrollbackonly (), setTransActionTimeout (). Use context.getusertransAction () to get UserTransaction.
l If you want the program to control the transaction, you must set
l When we start a transaction in the program, it is best to end this transaction in the same method, otherwise you will have a serious consumption system resource for a long time.
l If a function is in a transaction that has been created by other beans, how can this function destroy this transaction?
u In the container controlled transaction, you cannot destroy your business by throwing an abnormal means, because you throw an exception that you define your own, the container can't know if your own definition is serious to destroy the extent to destroy your business . So the transaction is ended because the context.setrollbackonly () method is used.
u If this function is a normal Java Object, you can find JTA first, then call the setRollbackOnly () method to end the transaction.
u If there is ten beans in a transaction, the second bean discovers errors and makes a setrollbackonly () operation, then the remaining beans can no longer do the same operation, because this will consume a large amount of resources. The state of the current transaction should be obtained, and the operation is performed according to this state. There are two ways to get the status of the transaction:
