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 DECEMBER 05, 2016

Applies to:

Oracle Weblogic Server - Version 10.3.4 to 10.3.6
Information in this document applies to any platform.

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

javax.ejb.EJBTransactionRequiredException: Method <method> is deployed as TX_MANDATORY, but it was called without a transaction.
at weblogic.ejb.container.internal.MethodDescriptor.getInvokeTxForBus(MethodDescriptor.java:487)
at weblogic.ejb.container.internal.EJBRuntimeUtils.createWrapWithTxsForBus(EJBRuntimeUtils.java:363)
at weblogic.ejb.container.internal.StatelessRemoteObject.__WL_preInvoke(StatelessRemoteObject.java:32)
at weblogic.ejb.container.internal.SessionRemoteMethodInvoker.invoke(SessionRemoteMethodInvoker.java:24)
at project_ejb.DestinationSessionEJB_278i6o_DestinationSessionEJBImpl.testSupport(Unknown Source)
at project_ejb.DestinationSessionEJB_278i6o_DestinationSessionEJBImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:667)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:522)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:518)
at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)



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.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms