Transaction propagation is not supported for Enterprise JavaBeans (EJB) remote interfaces

Liberty does not support outbound or inbound transaction propagation for EJB remote interfaces. By default, EJB beans are container-managed and use the Required transaction attribute. As a result, existing EJB definitions that do not specify any container-transaction properties are configured by default to use transactions although they are not supported.

This rule flags Java code that references the following EJB annotations that indicate the use of remote business or home interfaces:

This rule also flags the following references in the ejb-jar.xml file:

The EJB specification requires products that support outbound transaction propagation to still send a null transaction context. This context must be rejected by EJB components that use the Required (default), Mandatory , or Supports transaction attributes. A client with an active global transaction cannot start an EJB bean with default transaction attributes if either the client or server is on Liberty.

To enable the client to start the EJB bean, change the EJB bean to use either the RequiresNew or NotSupported transaction attribute. Although these attributes will allow the EJB bean to start, the transactional work that is done by the EJB bean is not committed as part of the client transactions.

Note that transaction propagation is supported for EJB remote interfaces that are running in the same JVM, however this may only be determined with further investigation of the application behavior.

Make sure remote EJB interfaces are needed

Often EJB 2.x beans configure the remote interfaces in ejb-jar.xml even when they are not used. You only need remote interfaces if you have code running across two different JVMs. In WebSphere terms, this is either between two different application servers or between a client application and an application server running in different JVMs. CORBA information, such as an iiop:// provider URL, in an EJB lookup is also an indicator that remote EJB beans are being used.

If you are referencing EJB beans using a remote interface that are running in the same JVM, the Local interface can be used and will perform better. Where possible, change annotations from @Remote to @Local and from @RemoteHome to @LocalHome and test all your code scenarios. Likewise for ejb-jar.xml configuration, remove the <remote/> and <business-remote/> definitions and test all scenarios. While transaction propagation is supported for this scenario, the best practice is to convert to using local interfaces to improve performance and remove the perception that methods can be called externally from the same JVM.

If you really need remote interfaces

Wrap the EJB beans in a web service (JAX-WS)

For those EJB beans that require remote access, best practice is to wrap them in a web service. Refer to Annotating an EJB bean to create a web service for instructions on using WebSphere Application Server Developer Tools for Eclipse to make these code changes. After wrapping the EJB beans in web services, use the web service client to call the EJB web service. After testing, you can remove the EJB remote annotations or configuration.

Handling Transaction Propagation
Liberty provides Web Services Atomic Transaction (WS-AT) support which enables distributed global transactions. When your EJB are deployed as web services, WS-AT can be used to manage the transactions. See Web Services Atomic Transaction overview for more information.

For more information on related topics, see