What are Bean-Managed Transactions?
Bean Managed Transactions are -
-Not supported in entity beans
-Either Session or Message Driven Beans can have Bean Managed Transactions.
-These transactions could be of two types:
a.JDBC Transactions:
- is controlled by the transaction manager of the DBMS.
-invoke the commit and rollback methods of the java.sql.Connection interface.
-The beginning of a transaction is implicit.
- A transaction begins with the first SQL statement that follows the most recent commit, rollback, or connect statement. (This rule is generally true, but may vary with DBMS vendor.)
b. JTA(Java Transaction API) Transactions:
-is controlled by the Java EE transaction manager which does not support nested transactions,means a new transaction cannot start unless previous one is finished.
-use when transaction can span updates to multiple databases from different vendors.
-invoke the begin, commit, and rollback methods of the javax.transaction.UserTransaction interface.
What are some tips for using bean-managed transaction demarcation?
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 j ava.sql.Connection.commit(),
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 EJBContext .getRollBackOnly(), and javax.ejb.EJBContext.setRollbackOnly() , use the corresponding JTA API calls.
What is JTS ?
JTS is Transaction related services and it specifies the implementation of a Transaction Manager, which supports the
A JTS Transaction Manager provides transaction services to the parties involved in distributed transactions: the application server, the resource manager, the standalone transactional application, and the Communication Resource Manager (CRM).JTS does not support nested transactions it means it can not start a new transaction unless the previous one is completed.
What are transaction properties?
Transactions must have four properties recalled with the acronym ACID: Atomicity, Consistency, Isolation and Durability.
-
Atomicity is "all or nothing" operation wherein, for example, a transaction consisting of a debit to one account and a credit to another is not committed unless both operations are successful. Typically, atomicity is provided by the database management system.
-
Consistency reflects the state of the system. A system is always consistent based upon the state invariants and transactions give the opportunity to write code that checks the consistency of the state.
-
Isolation keeps operations on shared data invisible across transactions.
-
Durability guarantees the effect of completed transaction are permanent and are not lost.
What are transaction attributes ? Which transaction attributes should I use in which situations?
The different Transaction Attributes are:-
Required
RequiresNew
Manadatory
Supports
Never
NotRequired
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 getEJBHome(), getHandle(), getPrimaryKey(), isIdentical() methods of the remote interface; and methods getEJBMetaData(), getHomeHandle() of the home interface.
-Use Required as the default transaction attribute, to ensure that methods are invoked within a Java Transaction API (JTA) transaction context. Required causes the enterprise bean to use existing transactional context if it exists, or to create one otherwise.
-Use RequiresNew when the results of the method must be committed regardless whether the caller's transaction succeeds. For example, a method that logs all attempted transactions, whether those transaction succeed or not, could use RequiresNew to add log entries. RequiresNew always creates a new transaction context before the method call, and commits or rolls back after the method call. Note that any existing client transaction context will be suspended until the method call returns.
-Use Supports for methods that either do not change the database (directly or indirectly); or update atomically, and it does not matter whether or not the update occurs within a transaction. Supports uses the client transaction context if it exists, or no transaction context otherwise.
-Use Mandatory when the method absolutely requires an existing transaction. Mandatory causes RemoteException to be thrown unless the client is associated with a transaction context.
-Use Never to ensure that a transactional client does not access methods that are not capable of participating in the transaction. Never causes RemoteException to be thrown if the client is associated with a transactional context.
-Use NotSupported when an enterprise bean accesses a resource manager that either does not support external transaction coordination, or is not supported by the J2EE product. In this case, the bean must have container-managed transaction demarcation, and all its methods must be marked NotSupported. NotSupported will result in the method being called outside of any transaction context, whether or not one exists.
Enterprise beans that implement interface SessionSynchronization must have either the Required, RequiresNew, or Mandatory transaction attribute.
Required
RequiresNew
Manadatory
Supports
Never
NotRequired
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 getEJBHome(), getHandle(), getPrimaryKey(), isIdentical() methods of the remote interface; and methods getEJBMetaData(), getHomeHandle() of the home interface.
-Use Required as the default transaction attribute, to ensure that methods are invoked within a Java Transaction API (JTA) transaction context. Required causes the enterprise bean to use existing transactional context if it exists, or to create one otherwise.
-Use RequiresNew when the results of the method must be committed regardless whether the caller's transaction succeeds. For example, a method that logs all attempted transactions, whether those transaction succeed or not, could use RequiresNew to add log entries. RequiresNew always creates a new transaction context before the method call, and commits or rolls back after the method call. Note that any existing client transaction context will be suspended until the method call returns.
-Use Supports for methods that either do not change the database (directly or indirectly); or update atomically, and it does not matter whether or not the update occurs within a transaction. Supports uses the client transaction context if it exists, or no transaction context otherwise.
-Use Mandatory when the method absolutely requires an existing transaction. Mandatory causes RemoteException to be thrown unless the client is associated with a transaction context.
-Use Never to ensure that a transactional client does not access methods that are not capable of participating in the transaction. Never causes RemoteException to be thrown if the client is associated with a transactional context.
-Use NotSupported when an enterprise bean accesses a resource manager that either does not support external transaction coordination, or is not supported by the J2EE product. In this case, the bean must have container-managed transaction demarcation, and all its methods must be marked NotSupported. NotSupported will result in the method being called outside of any transaction context, whether or not one exists.
Enterprise beans that implement interface SessionSynchronization must have either the Required, RequiresNew, or Mandatory transaction attribute.
How can you handle transaction isolation?
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 be modified. Entity beans using bean-managed persistence may use the underlying DBMS API to change the isolation level (using, for example, Connection.setTransactionIsolation().)
Additionally,a great portion of an application consists of simply fetching data from a DB. It is recommended to use 'Supported' for the transaction attribute of read-only operations. In such cases thee will be no transaction overhead if read only are the only operations in your transaction, but will be transactional if there are updates involved in the transaction.
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 be modified. Entity beans using bean-managed persistence may use the underlying DBMS API to change the isolation level (using, for example, Connection.setTransactionIsolation().)
Additionally,a great portion of an application consists of simply fetching data from a DB. It is recommended to use 'Supported' for the transaction attribute of read-only operations. In such cases thee will be no transaction overhead if read only are the only operations in your transaction, but will be transactional if there are updates involved in the transaction.
No comments:
Post a Comment