type=page
status=published
title=Bean-Managed Transactions
next=transactions006.html
prev=transactions004.html
~~~~~~
Bean-Managed Transactions
=========================

[[BNCIY]]

[[bean-managed-transactions]]
Bean-Managed Transactions
-------------------------

In bean-managed transaction demarcation, the code in the session or
message-driven bean explicitly marks the boundaries of the transaction.
Although beans with container-managed transactions require less coding,
they have one limitation: When a method is executing, it can be
associated with either a single transaction or no transaction at all. If
this limitation will make coding your bean difficult, you should
consider using bean-managed transactions.

The following pseudocode illustrates the kind of fine-grained control
you can obtain with application-managed transactions. By checking
various conditions, the pseudocode decides whether to start or stop
certain transactions within the business method:

[source,oac_no_warn]
----
begin transaction
...
    update table-a
...
    if (condition-x)
   commit transaction
    else if (condition-y)
   update table-b
   commit transaction
    else
   rollback transaction
   begin transaction
   update table-c
   commit transaction
----

When coding an application-managed transaction for session or
message-driven beans, you must decide whether to use Java Database
Connectivity or JTA transactions. The sections that follow discuss both
types of transactions.

[[BNCIZ]]

[[jta-transactions]]
JTA Transactions
~~~~~~~~~~~~~~~~

JTA, or the Java Transaction API, allows you to demarcate transactions
in a manner that is independent of the transaction manager
implementation. GlassFish Server implements the transaction manager with
the Java Transaction Service (JTS). However, your code doesn't call the
JTS methods directly but instead invokes the JTA methods, which then
call the lower-level JTS routines.

A JTA transaction is controlled by the Java EE transaction manager. You
may want to use a JTA transaction because it can span updates to
multiple databases from different vendors. A particular DBMS's
transaction manager may not work with heterogeneous databases. However,
the Java EE transaction manager does have one limitation: It does not
support nested transactions. In other words, it cannot start a
transaction for an instance until the preceding transaction has ended.

To demarcate a JTA transaction, you invoke the `begin`, `commit`, and
`rollback` methods of the `javax.transaction.UserTransaction` interface.

[[BNCJA]]

[[returning-without-committing]]
Returning without Committing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In a stateless session bean with bean-managed transactions, a business
method must commit or roll back a transaction before returning. However,
a stateful session bean does not have this restriction.

In a stateful session bean with a JTA transaction, the association
between the bean instance and the transaction is retained across
multiple client calls. Even if each business method called by the client
opens and closes the database connection, the association is retained
until the instance completes the transaction.

In a stateful session bean with a JDBC transaction, the JDBC connection
retains the association between the bean instance and the transaction
across multiple calls. If the connection is closed, the association is
not retained.

[[BNCJB]]

[[methods-not-allowed-in-bean-managed-transactions]]
Methods Not Allowed in Bean-Managed Transactions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Do not invoke the `getRollbackOnly` and `setRollbackOnly` methods of the
`EJBContext` interface in bean-managed transactions. These methods
should be used only in container-managed transactions. For bean-managed
transactions, invoke the `getStatus` and `rollback` methods of the
`UserTransaction` interface.


