Explain the different Transaction Attributes and Isolation Levels with reference to a scenario ?
The Enterprise JavaBeans model supports six different transaction rules:
- TX_BEAN_MANAGED. The TX_BEAN_MANAGED setting indicates that the enterprise bean manually manages its own transaction control. EJB supports manual transaction demarcation using the Java Transaction API. This is very tricky and should not be attempted without a really good reason.
- TX_NOT_SUPPORTED. The TX_NOT_SUPPORTED setting indicates that the enterprise bean cannot execute within the context of a transaction. If a client (i.e., whatever called the method-either a remote client or another enterprise bean) has a transaction when it calls the enterprise bean, the container suspends the transaction for the duration of the method call.
- TX_SUPPORTS. The TX_SUPPORTS setting indicates that the enterprise bean can run with or without a transaction context. If a client has a transaction when it calls the enterprise bean, the method will join the client's transaction context. If the client does not have a transaction, the method will run without a transaction.
- TX_REQUIRED. The TX_REQUIRED setting indicates that the enterprise bean must execute within the context of a transaction. If a client has a transaction when it calls the enterprise bean, the method will join the client's transaction context. If the client does not have a transaction, the container automatically starts a new transaction for the method. Attributes
- TX_REQUIRES_NEW. The TX_REQUIRES_NEW setting indicates that the enterprise bean must execute within the context of a new transaction. The container always starts a new transaction for the method. If the client has a transaction when it calls the enterprise bean, the container suspends the client's transaction for the duration of the method call.
- TX_MANDATORY. The TX_MANDATORY setting indicates that the enterprise bean must always execute within the context of the client's transaction. If the client does not have a transaction when it calls the enterprise bean, the container throws the TransactionRequired exception and the request fails.
The following are some of the points to be remembered when specifying transaction attributes for Enterprise JavaBeansTM-technology based components (EJBTM):
All methods of a session bean's remote interface (and super interfaces) must have specified transaction attributes.
Session bean home interface methods should not have transaction attributes.
(All methods of an entity bean's remote and home interfaces (and super interfaces) must have specified transaction attributes, with the exception of: methods
Enterprise beans that implement interface
The EJB specification indicates that the API for controlling transaction isolation level is specific to the resource manager implementation, and therefore the architecture does not define and isolation level control API.
If a container uses only one bean instance per primary key, the container will synchronize access to the bean and therefore transaction isolation is unnecessary. Containers that use multiple instances per primary key depend on the underlying database for isolation.
Enterprise beans using container-managed persistence use the default isolation level of the underlying database; therefore, the isolation level cannot modified. Entity beans using bean-managed persistence may use the underlying DBMS API to change the isolation level (using, for example,
Yes, the J2EE platform allows multiple databases to participate in a transaction. These databases may be spread across multiple machines, using multiple EJB technology-enabled servers from multiple vendors.
No, the J2EE platform supports only flat transactions.
Session beans should use bean-managed transaction demarcation, although can use container-managed demarcation. Entity beans must use container-managed demarcation.
An enterprise bean should not invoke resource manager-specific transition demarcation API methods (like java.sql.Connection.commit(), java.sql.Connection.rollback(), etc.) while within a transaction.
Stateless session beans should always either commit or rollback a transaction before the business method returns. Stateful session beans do not have this requirement. Instead of calling
Do not invoke a resource-manager-specific transaction demarcation API (like
Avoid using interface
Implement rollbacks by calling
No. Entity beans always use container-managed transaction demarcation. Session beans can use either container-managed or bean-managed transaction demarcation, but not at the same time.
No. Simply putting a transactional attribute on a method won't help if the resource manager can't use a transactional context.
A bean instance that executes in an XA or a global transaction should not use multiple connections to the same resource manager.
Specifically, a bean instance that executes in an XA transaction should not cache more than one connection to the same resource manager. Further, it should not create more than one connection to the same resource manager from within a bean method under a single XA transaction.
This is needed because even though XA allows multiple connections to be enlisted in a single transaction branch, there are some restrictions. Some resource managers do not allow more than one connection to be simultaneously enlisted in the same transaction branch.
Note however that within a single XA transaction, there can be more than one connection to a single resource manager, spread across different bean instances.
| || |