Hi all,

A coworker has discovered an interesting behavior in WebSphere Application Server. The situation is that one stateless session bean (Bean A) calls the remote method of another stateless session bean (Bean B). Both are using CMT and all methods involved a transaction attribute of Required. When setRollbackOnly is called from Bean A the method returns to the caller without throwing an exception. However when Bean B calls setRollbackOnly, the call to Bean B throws TransactionRolledbackException.

The EJB spec doesn't appear to handle this explicitly. I found the following which would apply:

17.6.2.8 Handling of setRollbackOnly Method

The container must handle the EJBContext.setRollbackOnly method invoked from a business method executing with the Required, RequiresNew, or Mandatory 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.
  • If the container initiated the transaction immediately before dispatching the business method to the instance (as opposed to the transaction being inherited from the caller), the container must note that the instance has invoked the setRollbackOnly method. When the business method invocation completes, the container must roll back rather than commit the transaction. If the business method has returned normally or with an application exception, the container must pass the method result or the application exception to the client after the container performed the rollback.
This would indicate that having an exception thrown when the setRollbackOnly is in a nested call is OK. However, I have a hard time believing this since one of the benefits of EJBs is location independence.

And just to be contrary the following from Section 18.3.9 appears to say the an exception can never be thrown by a method were setRollbackOnly was invoked.
However, the container should not throw the java.rmi.RemoteException or javax.ejb.EJBException if the container performs a transaction rollback because the instance has invoked the setRollbackOnly method on its EJBContext object. In this case, the container must rollback the transaction and pass the business method result or the application exception thrown by the business method to the client.
WAS Support seems to believe that this doesn't apply to the situation I've mentioned above. Their rational is that the container isn't throwing the TRBE but the client "container" is throwing the TRBE. Talk about splitting hairs.

Has anyone else seen this behavior before? Does anyone have an opinion as to what's intended by the spec?

Thanks,

Victor Langelo


=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to