Business Logic Using EJB - Introducing Java EE 7 - page 73

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
@PreDestroy
public void destroy() {
System.out.println("The Acme Bean is being destroyed...");
em.flush();
}
}

Note that the @TransactionAttribute annotation is used to specify the transaction type of the callback method,
if needed. The annotation accepts a transaction type as per the values listed in Table 5-1 .

Table 5-1. Container-Managed Transaction Demarcation

Attribute Description

MANDATORY

The container must invoke an enterprise bean method whose transaction is set to this attribute
in the client's transaction context. The client is required to call with a transaction context.

REQUIRED

The container must invoke an enterprise bean method whose transaction is set to this attribute
value with an unspecified transaction context.

REQUIRES_NEW

The container must invoke an enterprise bean method whose transaction is set to this attribute
value with a new transaction context.

SUPPORTS

If the client calls with a transaction context, then the container treats it as REQUIRED . If the client
calls without a transaction context, the container treats it as NOT_SUPPORTED .

NOT_SUPPORTED

The container invokes an enterprise bean method whose transaction attribute is set to this value
with an unspecified transaction context.

NEVER

The container invokes an enterprise bean method whose transaction is set to this value without
a transaction context defined by the EJB specification.

By default, the life-cycle callback methods are not transactional in order to maintain backward compatibility.
By annotating the callback method with the @TransactionAttribute and the preferred demarcation type,
the callback method has opted in to be transactional.
To see the complete example of a transactional life-cycle callback, deploy the demo application for this topic and
look at the Chapter 5 transactional examples. When you visit the web page for the example, the AcmeFacade session
bean is initialized, and the message is printed to the system log.

Passivation Made Optional
When a stateful session bean has been inactive for a period of time, the container may choose to passivate the bean
in an effort to conserve memory and resources. Typically, the EJB container will passivate stateful session beans
using a least recently used algorithm. When passivation occurs, the bean is moved to secondary storage and removed
from memory. Prior to the passivation of a stateful session bean, any methods annotated with @PrePassivate will
be invoked. When a stateful session bean that has been passivated needs to be made active again, the EJB container
activates the bean, then calls any methods annotated with @PostActivate , and finally moves the bean to the ready
stage. In EJB 3.2, stateful session beans can opt out of passivation so that they will remain in memory instead of being
transferred to secondary storage if inactive. This may be helpful in situations where a bean needs to remain active for
application processes or where the bean contains a nonserializable field, since these fields cannot be passivated and
are made null upon passivation.