Integrating the Unit of Work with CMP

All modifications to persistent beans should be carried out in the context of a transaction.

Modifying entity beans without a transaction can lead to an inconsistent state, potentially corrupting the values in the TopLink cache. Because of this, TopLink does not support modifying a bean through its remote interface when no transaction is active. If you attempt to do so, TopLink simply does not write changes to the database.

Although TopLink does not let you modify an entity bean through its remote interface without a transaction, TopLink does let you invoke methods on its home interface that change the state in the underlying database without a transaction. For example, you may invoke remove and create methods on the home interface of an entity bean without a transaction.

To integrate TopLink transactions and the unit of work with container-managed persistence (CMP), you must consider the following:

CMP Transaction Attribute
Local Transactions
Nondeferred Changes

CMP Transaction Attribute

To ensure that all modifications to persistent beans are carried out in the context of a transaction, transactional attributes must be properly specified in the bean deployment descriptors.

The transaction may be either client-controlled or container-controlled.

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 102-3 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.

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

Table 102-3 EJB Transaction State 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

Depending on the CMP container you use, you may be able to write without a container-controlled transaction (see "Integrating the Unit of Work With an External Transaction Service"). In this case, TopLink automatically uses a transaction of its own, referred to as a local transaction (see "Local Transactions").

Local Transactions

Some CMP containers (such as OC4J) support writing without an active JTA transaction.

If you execute a bean method outside a JTA transaction while the transaction attribute (see "CMP Transaction Attribute") is set to Supports, NotSupported, or Never, TopLink performs the operation within a local unit of work and commits the unit of work at the end of the method. This unit of work is referred to as a local transaction.

The reason for this is because the update semantics in the EJB specification are left undefined for these scenarios, and a proper transactional model demands that a transaction be active before being able to modify data. TopLink also requires change operations to occur within a unit of work to ensure that the session cache remains consistent.

Nondeferred Changes

Some CMP containers (such as OC4J) support nondeferred changes: the ability to modify the data source immediately as you change the persistent fields of an entity bean.

Using nondeferred changes, you can achieve backwards compatibility with the native behavior of some CMP containers (such as OC4J) and you can accommodate advanced applications that rely on the database and entity changes being synchronized for such things as triggers or stored procedures based on transient state within the transaction, deletion and creation of rows with the same primary key, or other complex queries that depend on transient transaction state.

Nondeferred changes have the disadvantage of being the least efficient approach: they produce the greatest number of data source interactions.

By default, TopLink defers all changes until commit time. This is the most efficient approach that produces the least number of data source interactions.

For more information, see "Nondeferred Changes".