|Oracle8i Enterprise JavaBeans Developer's Guide and Reference
Release 3 (8.1.7)
Part Number A83725-01
Server-side demarcation can occur either implicitly through container-managed transaction or explicitly through bean-managed transactions. A container-managed transaction is specified within the EJB deployment descriptor for the bean. Most EJBs use container-managed transactions as it requires no transaction implementation within the application.
No matter which way that the server object decides to demarcate transactions, the enlistment of the database is the same for both container and bean-managed transactions.
You can declare that the container manages the transaction for the bean within the EJB deployment descriptor. This requires that you specify "
Container" within the
<transaction-type> element and the container-managed transaction attribute (see Table 7-1) within the
<container-transaction> element. See "Defining Transactions" for full instructions.
Based upon the transaction attribute you specify within the EJB deployment descriptor, the container will begin, commit, or rollback global transactions when a method in the bean instance is invoked. Each bean can be specified with different transaction attributes. The transaction attributes specify how the transaction demarcation is handled. This means that your bean does not retrieve the
UserTransaction object, nor invokes any of its methods. The container does this for you.
The container does not enlist the database resources for you. Bind each
DataSource within the namespace as indicated within Table 7-5. Your code enlists each database by retrieving the database connection through one of the methods listed in Table 7-2. A full example using container-managed transactional beans and database enlistment is shown in the section "Configuring Two-Phase Commit Engine".
Only session beans have the option to use bean-managed transactions. This means that only session beans can demarcate the transaction with the
rollback methods. In order to specify that this session bean is going to programmatically demarcate its transaction, it must specify the following in its EJB deployment descriptor:
<enterprise-beans> <session> . . .
See "Defining Transactions" for a full description of defining transaction management in the EJB deployment descriptor.
The session bean implementation demarcates transactions in the same manner as a client would. It invokes the
rollback methods off of the
UserTransaction object. The only difference is how the
UserTransaction object is retrieved. There are two methods for retrieving the
UserTransaction object on the server side in a bean-managed transactional bean:
SessionContext getUserTransaction method
The bean retrieves the
UserTransaction object from the
SessionContext object, which was set within the
setSessionContext method. This is the EJB 1.0 methodology for retrieving the
UserTransaction object and can only be used in a single-phase commit environment.
The container has already retrieved the
UserTransaction object for you. The following shows that the session context is saved in the
Within the bean implementation, retrieve the
UserTransaction from the session context and begin the transaction.
The EJB 1.1 method retrieves the
UserTransaction object by performing an in-session lookup with the following JNDI name: "
java:comp/UserTransaction". In a single-phase commit environment, the container will create the
UserTransaction object for you; in a two-phase environment, you must have already bound a
UserTransaction object with the two-phase commit information (username, password, and two-phase commit URL) into the namespace. After retrieval, you use this object to demarcate your global transaction.
The following demonstrates retrieving a
UserTransaction object from the namespace:
ic = new InitialContext ( ); // lookup the usertransaction UserTransaction ut = (UserTransaction)ic.lookup ("java:comp/UserTransaction"); ut.begin (); ...