EJB-CMT-Container-Managed Transactions官网原文
来源:互联网 发布:西财财经大学网络 编辑:程序博客网 时间:2024/06/05 04:03
Container-Managed Transactions
In an enterprise bean with container-managed transaction demarcation, the EJB container sets the boundaries of the transactions. You can use container-managed transactions with any type of enterprise bean: session or message-driven. Container-managed transactions simplify development because the enterprise bean code does not explicitly mark the transaction’s boundaries. The code does not include statements that begin and end the transaction. By default, if no transaction demarcation is specified, enterprise beans use container-managed transaction demarcation.
Typically, the container begins a transaction immediately before an enterprise bean method starts and commits the transaction just before the method exits. Each method can be associated with a single transaction. Nested or multiple transactions are not allowed within a method.
Container-managed transactions do not require all methods to be associated with transactions. When developing a bean, you can set the transaction attributes to specify which of the bean’s methods are associated with transactions.
Enterprise beans that use container-managed transaction demarcation must not use any transaction-management methods that interfere with the container’s transaction demarcation boundaries. Examples of such methods are the commit, setAutoCommit, and rollback methods of java.sql.Connection or thecommit and rollback methods of javax.jms.Session. If you require control over the transaction demarcation, you must use application-managed transaction demarcation.
Enterprise beans that use container-managed transaction demarcation also must not use the javax.transaction.UserTransaction interface.
Transaction Attributes
A transaction attribute controls the scope of a transaction. Figure 44-1 illustrates why controlling the scope is important. In the diagram, method-A begins a transaction and then invokes method-B of Bean-2. When method-B executes, does it run within the scope of the transaction started by method-A, or does it execute with a new transaction? The answer depends on the transaction attribute of method-B.
A transaction attribute can have one of the following values:
Required
RequiresNew
Mandatory
NotSupported
Supports
Never
Required Attribute
If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container starts a new transaction before running the method.
The Required attribute is the implicit transaction attribute for all enterprise bean methods running with container-managed transaction demarcation. You typically do not set the Required attribute unless you need to override another transaction attribute. Because transaction attributes are declarative, you can easily change them later.
RequiresNew Attribute
If the client is running within a transaction and invokes the enterprise bean’s method, the container takes the following steps:
Suspends the client’s transaction
Starts a new transaction
Delegates the call to the method
Resumes the client’s transaction after the method completes
If the client is not associated with a transaction, the container starts a new transaction before running the method.
You should use the RequiresNew attribute when you want to ensure that the method always runs within a new transaction.
Mandatory Attribute
If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container throws a TransactionRequiredException.
Use the Mandatory attribute if the enterprise bean’s method must use the transaction of the client.
NotSupported Attribute
If the client is running within a transaction and invokes the enterprise bean’s method, the container suspends the client’s transaction before invoking the method. After the method has completed, the container resumes the client’s transaction.
If the client is not associated with a transaction, the container does not start a new transaction before running the method.
Use the NotSupported attribute for methods that don’t need transactions. Because transactions involve overhead, this attribute may improve performance.
Supports Attribute
If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container does not start a new transaction before running the method.
Because the transactional behavior of the method may vary, you should use the Supports attribute with caution.
Never Attribute
If the client is running within a transaction and invokes the enterprise bean’s method, the container throws a RemoteException. If the client is not associated with a transaction, the container does not start a new transaction before running the method.
Summary of Transaction Attributes
Table 44-1 summarizes the effects of the transaction attributes. Both the T1 and the T2 transactions are controlled by the container. A T1 transaction is associated with the client that calls a method in the enterprise bean. In most cases, the client is another enterprise bean. A T2 transaction is started by the container just before the method executes.
In the last column of Table 44-1, the word “None” means that the business method does not execute within a transaction controlled by the container. However, the database calls in such a business method might be controlled by the transaction manager of the database management system.
Transaction Attribute
Client’s Transaction
Business Method’s Transaction
Required
None
T2
Required
T1
T1
RequiresNew
None
T2
RequiresNew
T1
T2
Mandatory
None
Error
Mandatory
T1
T1
NotSupported
None
None
NotSupported
T1
None
Supports
None
None
Supports
T1
T1
Never
None
None
Never
T1
Error
Setting Transaction Attributes
Transaction attributes are specified by decorating the enterprise bean class or method with a javax.ejb.TransactionAttribute annotation and setting it to one of the javax.ejb.TransactionAttributeType constants.
If you decorate the enterprise bean class with @TransactionAttribute, the specified TransactionAttributeType is applied to all the business methods in the class. Decorating a business method with @TransactionAttribute applies the TransactionAttributeType only to that method. If a@TransactionAttribute annotation decorates both the class and the method, the method TransactionAttributeType overrides the classTransactionAttributeType.
The TransactionAttributeType constants shown in Table 44-2 encapsulate the transaction attributes described earlier in this section.
Transaction Attribute
TransactionAttributeType Constant
Required
TransactionAttributeType.REQUIRED
RequiresNew
TransactionAttributeType.REQUIRES_NEW
Mandatory
TransactionAttributeType.MANDATORY
NotSupported
TransactionAttributeType.NOT_SUPPORTED
Supports
TransactionAttributeType.SUPPORTS
Never
TransactionAttributeType.NEVER
The following code snippet demonstrates how to use the @TransactionAttribute annotation:
@TransactionAttribute(NOT_SUPPORTED)@Statefulpublic class TransactionBean implements Transaction {... @TransactionAttribute(REQUIRES_NEW) public void firstMethod() {...} @TransactionAttribute(REQUIRED) public void secondMethod() {...} public void thirdMethod() {...} public void fourthMethod() {...}}
In this example, the TransactionBean class’s transaction attribute has been set to NotSupported, firstMethod has been set to RequiresNew, andsecondMethod has been set to Required. Because a @TransactionAttribute set on a method overrides the class @TransactionAttribute, calls tofirstMethod will create a new transaction, and calls to secondMethod will either run in the current transaction or start a new transaction. Calls to thirdMethod orfourthMethod do not take place within a transaction.
Rolling Back a Container-Managed Transaction
There are two ways to roll back a container-managed transaction. First, if a system exception is thrown, the container will automatically roll back the transaction. Second, by invoking the setRollbackOnly method of the EJBContext interface, the bean method instructs the container to roll back the transaction. If the bean throws an application exception, the rollback is not automatic but can be initiated by a call to setRollbackOnly.
Synchronizing a Session Bean’s Instance Variables
The SessionSynchronization interface, which is optional, allows stateful session bean instances to receive transaction synchronization notifications. For example, you could synchronize the instance variables of an enterprise bean with their corresponding values in the database. The container invokes theSessionSynchronization methods (afterBegin, beforeCompletion, and afterCompletion) at each of the main stages of a transaction.
The afterBegin method informs the instance that a new transaction has begun. The container invokes afterBegin immediately before it invokes the business method.
The container invokes the beforeCompletion method after the business method has finished but just before the transaction commits. The beforeCompletionmethod is the last opportunity for the session bean to roll back the transaction (by calling setRollbackOnly).
The afterCompletion method indicates that the transaction has completed. This method has a single boolean parameter whose value is true if the transaction was committed and false if it was rolled back.
Methods Not Allowed in Container-Managed Transactions
You should not invoke any method that might interfere with the transaction boundaries set by the container. The list of prohibited methods follows:
The commit, setAutoCommit, and rollback methods of java.sql.Connection
The getUserTransaction method of javax.ejb.EJBContext
Any method of javax.transaction.UserTransaction
You can, however, use these methods to set boundaries in application-managed transactions.
- EJB-CMT-Container-Managed Transactions官网原文
- 浅琢Container-Managed Transaction
- 关于ejb中的BMT和CMT
- 事务—EJB事务(CMT)
- EJB之BMT事务和CMT事务
- EJB 3事务之:容器管理事务(CMT)
- EJB 3事务之容器管理事务(CMT)
- EJB 3事务之容器管理事务(CMT)
- Java容器(Web Container, EJB Container)
- EJB (四) EJB Container Manage Transaction
- Rolling Back a Container-Managed Transaction
- Transactions
- SCEA之路--7. EJB CONTAINER MODEL
- EJB Container/server 提供的服务
- EJB Container/server 提供的服务[转载]
- Embedded Container for EJB test(原创)
- EJB 3事务之容器管理事务(CMT)BEAN管理事务
- EJB 3事务之容器管理事务(CMT)BE…
- 《iPhone 3D 编程》第二章:数学与抽象
- 【查找结构】动态查找树比较
- FTPClient 简介
- sql2000,理论。
- Java对象的序列化ObjectInputStream与ObjectOutputStream
- EJB-CMT-Container-Managed Transactions官网原文
- 韩冀中谈Hadoop【转自图灵网】
- keystore提取私钥和证书
- Java 使用FTPClient实现上传下载
- jQuery cdn
- assert用法总结
- ch02 脚本基础
- 架构师接龙:盛大许式伟 VS 金山张宴
- Wijmo 更优美的jQuery UI部件集:复合图表(CompositeChart)