Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Enterprise JavaBeans™ Specification, Version 2.0 - Sun Microsystems.pdf
Скачиваний:
14
Добавлен:
24.05.2014
Размер:
2.71 Mб
Скачать

Sun Microsystems Inc.

Support for Transactions

Enterprise JavaBeans 2.0, Public Draft

Container Provider responsibilities

16.7.2.9 Handling of getRollbackOnly() method

The Container must handle the EJBContext.getRollbackOnly() method invoked from a business method executing with the Required, RequiresNew, or Mandatory transaction attribute.

The Container must throw the java.lang.IllegalStateException if the EJBContext.getRollbackOnly() method is invoked from a business method executing with the Supports, NotSupported, or Never transaction attribute.

16.7.2.10 Handling of getUserTransaction() method

If an instance of an enterprise bean with container-managed transaction demarcation attempts to invoke the getUserTransaction() method of the EJBContext interface, the Container must throw the java.lang.IllegalStateException.

16.7.2.11 javax.ejb.SessionSynchronization callbacks

If a Session Bean class implements the javax.ejb.SessionSynchronization interface, the Container must invoke the afterBegin(), beforeCompletion(), and afterCompletion(...) callbacks on the instance as part of the transaction commit protocol.

The Container invokes the afterBegin() method on an instance before it invokes the first business method in a transaction.

The Container invokes the beforeCompletion() method to give the enterprise bean instance the last chance to cause the transaction to rollback. The instance may cause the transaction to roll back by invoking the EJBContext.setRollbackOnly() method.

The Container invokes the afterCompletion(Boolean committed) method after the completion of the transaction commit protocol to notify the enterprise bean instance of the transaction outcome.

16.7.3 Container-managed transaction demarcation for Message-driven Beans

The Container is responsible for providing the transaction demarcation for the message-driven beans that the Bean Provider declared as with container-managed transaction demarcation. For these enterprise beans, the Container must demarcate transactions as specified in the deployment descriptor by the Application Assembler. (See Chapter 21 for more information about the deployment descriptor.)

The following subsections define the responsibilities of the Container for managing the invocation of a message-driven bean’s onMessage method. The Container’s responsibilities depend on the value of the transaction attribute.

Only the NotSupported and Required transaction attributes may be used for message-driven beans. The use of the other transaction attributes is not meanigful for message-driven beans because there can be no pre-existing transaction context (RequiresNew, Supports) and no client to handle exceptions (Mandatory, Never).

5/31/00

332

Sun Microsystems Inc

Container Provider responsibilities

Enterprise JavaBeans 2.0, Public Draft

Support for Transactions

16.7.3.1 NotSupported

The Container invokes a message-driven Bean method whose transaction attribute is set to NotSupported with an unspecified transaction context.

If the onMessage method invokes other enterprise beans, the Container passes no transaction context with the invocation.

16.7.3.2 Required

The Container must invoke a message-driven Bean method whose transaction attribute is set to Required with a valid transaction context. Because there is never a client transaction context available for a message-driven bean, the container automatically starts a new transaction before the dequeuing of the JMS message and, hence, before the invocation of the message-driven bean’s onMessage method. The Container automatically enlists the resource manager associated with the arriving message and all the resource managers accessed by the onMessage method with the transaction. If the onMessage method invokes other enterprise beans, the Container passes the transaction context with the invocation. The Container attempts to commit the transaction when the onMessage method has completed. If the onMessage method does not successfully complete or the transaction is rolled back by the Container, JMS message redelivery semantics apply.

16.7.3.3 Handling of setRollbackOnly() method

The Container must handle the EJBContext.setRollbackOnly() method invoked from a onMessage method executing with the Required transaction attribute as follows:

The Container must ensure that the transaction will never commit. Typically, the Container instructs the transaction manager to mark the transaction for rollback.

The Container must note that the instance has invoked the setRollbackOnly() method. When the method invocation completes, the Container must roll back rather than commit the transaction.

The Container must throw and log the java.lang.IllegalStateException if the EJBContext.setRollbackOnly() method is invoked from an onMessage method executing with the NotSupported transaction attribute

16.7.3.4 Handling of getRollbackOnly() method

The Container must handle the EJBContext.getRollbackOnly() method invoked from an onMessage method executing with the Required transaction attribute.

The Container must throw and log the java.lang.IllegalStateException if the EJBContext.getRollbackOnly() method is invoked from an onMessage method executing with the NotSupported transaction attribute

333

5/31/00