Understanding EJB Transaction Services

You can enable OC4J to manage transactions by using the Java Transaction API (JTA) supported by the Java Transaction Service (JTS). Using annotations or the deployment descriptor, you define the transactional properties of EJBs during design or deployment and then let the OC4J take over the responsibility of transaction management.

All entity beans with CMP and CMR relationships must be involved in a transaction. As such, you cannot define any entity bean with a transaction attribute of NEVER, SUPPORTS, or NOT_REQUIRED as this would put the entity outside of a transaction.

This section describes:

Who Manages a Transaction?
Who Begins and Commits a Transaction?
How do I Participate in a Global or Two-Phase Commit Transaction?

For more information, see:

"Configuring Transaction Services"
"Transaction Best Practices"
"OC4J Transaction Support" in the Oracle Containers for J2EE Services Guide

Who Manages a Transaction?

A transaction can be managed by either the container (see "Container-Managed Transaction (CMT)") or the bean ("Bean-Managed Transaction (BMT)").

Container-Managed Transaction (CMT)

When you use container-managed transactions, your EJB delegates to the container the responsibility to ensure that a transaction is started and committed when appropriate.

Using EJB 3.0, you can use either CMT or BMT (see "Bean-Managed Transaction (BMT)").

Using EBJ 2.1, you can only use CMT.

Bean-Managed Transaction (BMT)

When you use bean-managed transactions, the bean-provider is responsible for ensureing that a transaction is started and committed when appropriate.

Using EJB 3.0, you can use either BMT or CMT (see "Container-Managed Transaction (CMT)").

Using EBJ 2.1, you can only use CMT.

Who Begins and Commits a Transaction?

Client-controlled transactions are started explicitly by your application by way of the javax.transaction.UserTransaction interface.

Container-controlled transactions are started implicitly by the container to satisfy the transaction attribute configuration when a bean method is invoked in the absence of a client-controlled transaction.

Table 2-6 shows what transaction (if any) an EJB method invocation uses depending on how its transaction attribute is configured and whether or not a client-controlled transaction exists at the time the method is invoked.

Table 2-6 EJB Transaction Support by Transaction Attribute

Transaction Attribute	Client-Controlled Transaction Exists	Client-Controlled Transaction Does Not Exist
`NotSupported`	Use no transaction	Use no transaction
`Supports`	Use client-controlled transaction	Use no transaction
`Required`	Use client-controlled transaction	Use container-controlled transaction
`RequiresNew`	Use client-controlled transaction	Use container-controlled transaction
`Mandatory`	Use client-controlled transaction	Exception raised
`Never`	Exception raised	Use no transaction

Oracle recommends that you do not make modifications to entity beans under conditions identified as "Use no transaction". Oracle also recommends that you avoid using the Supports transaction attribute because it leads to a non-transactional state whenever the client does not explicitly provide a transaction.

This applies to both EJB 3.0 and EJB 2.1.

How do I Participate in a Global or Two-Phase Commit Transaction?

If all resources enlisted in a transaction are XA-compliant then OC4J automatically coordinates a global or two-phase commit transaction.

In this release, transaction coordination functionality is now located in OC4J, replacing in-database coordination, which is now deprecated. Also, the middle-tier coordinator is now "heterogeneous", meaning that it supports all XA-compatible resources, not just those from Oracle.

The middle-tier coordinator provides the following features:

Supports any XA compliant resource
Supports interpositioning and transaction inflow
Last resource commit optimization
Recovery logging

For more information, see "Middle-Tier Two-Phase Commit (2PC) Coordinator" in the Oracle Containers for J2EE Services Guide.