Error "javax.ejb.EJBTransactionRequiredException: Method <name> is deployed as TX_MANDATORY, but it was called without a transaction" After Updating of EJB "Server" Application in WebLogic Server 10.3 (Doc ID 1397613.1)

Last updated on AUGUST 15, 2022

Applies to:

Symptoms

WebLogic Server versions 10.3.4 to 10.3.6 are unable to update EJB distributed applications to contain new methods without a complete undeployment and a later deployment of the EJB application.

The problem is reproduced when you have an EJB Distributed application (typical of "client" ear invoking "server") as in the following scenario:

1) EJB1 application in server1 (containing stateless session beans ) acting as "client"
2) EJB2 application in server2 (containing stateless session beans ) acting as "server"
3) A java client is used to call EJB1 SLSB  which invokes EJB2 SLSB using a single transaction.

When the applications are repackaged as follows :

1) EJB2 ear file is repackaged to contain a new method named as method2 to have TransactionAttributeType.MANDATORY

2) EJB1 ear file is repackaged to contain a new method named as method1 to have TransactionAttributeType.REQUIRED, which invokes EJB2 SLSB method2

3) Change java client application to invoke EJB1 SLSB method1 so that all the new existing methods are invoked.

4) And then redeploy the application by UPDATING it in the target servers (being that done from AdminServer console or from weblogic.deployer). For that...

a) Copy the new version of the EAR files to <domain>\servers\AdminServer\upload , making sure you overwrite the existing ones.

b) From the console, go to Domain -> Deployments
Select EJB1 application and update it with the same location ear file
Select EJB2 application and update it with the same location ear file

5) The following invocation of java client application to execute EJB1 SLSB method1 fails with error

6) All the previous existing methods in EJB1 and EJB2 from previous version of the application do work correctly.

The only available workaround is to completely undeploy EJB1 and EJB2 applications and then deploy them as new applications, causing service disruption.

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.