Cannot access an enterprise bean from a servlet, JSP file, stand-alone program, or other client

What kind of error are you seeing?

  1. javax.naming.NameNotFoundException: Name name not found in context "local" message when access is attempted

  2. BeanNotReentrantException is thrown

  3. CSITransactionRolledbackException / TransactionRolledbackException is thrown

  4. Call fails, Stack trace beginning EJSContainer E Bean method threw exception [exception_name] found in JVM log file.

  5. Call fails, ObjectNotFoundException or ObjectNotFoundLocalException when accessing stateful session EJB found in JVM log file.

  6. Attempt to start CMP EJB module fails with javax.naming.NameNotFoundException: dataSourceName

  7. Transaction [tran ID] has timed out after 120 seconds error accessing EJB.

  8. Symptom: CNTR0001W: A Stateful SessionBean could not be passivated

  9. Symptom: org.omg.CORBA.BAD_PARAM: Servant is not of the expected type. minor code: 4942F21E completed: No returned to client program when attempting to execute an EJB method

If the client is remote to the enterprise bean, which means, running in a different appserver or as a stand-alone client, browse theJVM logs of the application server hosting the enterprise bean as well as log files of the client.

If you do not see a problem that resembles yours, or if the information provided does not solve your problem, perform these steps:

  1. If the problem appears to be Name-Service related, which means that you see a NameNotFoundException, or a message ID beginning with NMSV, see these topics for more information:

  2. Check to see if the problem has been identified and documented using the links in Diagnosing and fixing problems: Links.
If you still cannot fix your problem, contact IBM support for further assistance.

 

ObjectNotFoundException or ObjectNotFoundLocalException when accessing stateful session EJB

A possible cause of this problem is that the stateful session bean timed out and was removed by the container. This event must be coded for, according to the EJB 2.0 specification (available at http://java.sun.com/products/ejb/docs.html), section 7.6.2, Dealing with exceptions.

 

Stack trace beginning "EJSContainer E Bean method threw exception [exception_name]" found in JVM log file

If the "exception name" indicates an exception thrown by an IBM class, that is it begins "com.ibm...", then search for the exception name within this InfoCenter, and in the online help as described below. If "exception name" indicates an exception thrown by your application, contact the application developer to determine what might have caused it.

 

javax.naming.NameNotFoundException: Name name not found in context "local"

A possible reason for this is exception is that the enterprise bean is not local (not running in the same Java Virtual Machine [JVM] or Application Server) to the client JSP, servlet, Java application, or other enterprise bean, yet the call is to one of the enterprise bean's "local" interface methods. If access worked in a development environment but not when deployed to WebSphere Application Server, for example, it could be that the enterprise bean and its client were in the same JVM in development, but after deployment they are in separate processes.

To resolve this problem, contact the developer of the enterprise bean and determine whether the client call is to a method in the enterprise bean's local interface. If so, have the client code changed to call a remote interface method, or promote the local method into the remote interface.

References to enterprise beans with local interfaces are bound in a name space local to the server process with the URL scheme of local: . To obtain a dump of a server local: name space, use the name space dump utility described in the article "Name space dump utility for, and name spaces."

 

BeanNotReentrantException is thrown

This problem can be caused by client code (typically a servlet or JSP) attempting to call the same stateful SessionBean from two different client threads. This situation often arises when the an application stores the reference to the stateful session bean in a static variable, uses a global (static) JSP variable to refer to the stateful SessionBean reference, or stores the stateful SessionBean reference in the HTTP session object and then has the client browser issue a new request to the servlet or JSP before the previous request has completed.

To resolve this problem, ask the developer of the client code to review their code for these conditions.

 

CSITransactionRolledbackException / TransactionRolledbackException is thrown

These are high-level exceptions thrown by an enterprise bean's container, and indicate that an enterprise bean call could not be successfully completed. When this exception is thrown, browse the JVM logs to determine the underlying cause.

Some possible causes are:

  • The enterprise bean may be throwing an exception that was not declared as part of its method signature. The container is required to roll back the transaction in this case. Common causes of this situation are where the enterprise bean or code that it calls throws a NullPointerException, ArrayIndexOutOfBoundsException, or other Java "runtime" exception, or where a BMP bean encounters a JDBC error. The resolution is to investigate the enterprise bean code and resolve the underlying exception, or to add the exception to the problem method's signature.

  • A transaction may have attempted to do additional work after being placed in a "Marked Rollback" , "RollingBack" , or "RolledBack" state. Transactions cannot continue to do work after they have been set to one of these states. Often this occurs because the transaction has timed out which, in turn, often occurs because of a database deadlock. The resolution is to work with the application's database managements tools or administrator to determine whether database transactions called by the enterprise bean are timing out.

  • A transaction may fail on commit due to "dangling work". This could be due to "local" transactions. The local transaction encountered some "dangling work" during commit. The default "action" for local transactions when they encounter an "Unresolved Action" is to "rollback". This can be adjusted to "commit" in the Application Assembly Tool. In the AAT, open the enterprise bean .jar file (or the EAR file containing the enterprise bean) and select the "Session Beans" or "Entity Beans" object in the component tree on the left. The "Unresolved Action" property is on the "IBM Extensions" tab of the container properties.

 

Attempt to start EJB module fails with "javax.naming.NameNotFoundException dataSourceName_CMP"exception

The possible causes of this problem are:

 

Transaction [tran ID] has timed out after 120 seconds accessing EJB

This error can happen when a client executes a transaction on a CMP or BMP enterprise bean.

  • The default timeout value for enterprise bean transactions is 120 seconds. After this time, the transaction times out and the connection is closed.

  • If the transaction legitimately takes longer than the specified timeout period, go to Manage Application Servers -> server_name, select the Transaction Service properties page, and look at the property Total transaction lifetime timeout. Increase this value if necessary and save the configuration.

 

Symptom:CNTR0001W: A Stateful SessionBean could not be passivated

This error can occur when a Connection Object being used in the bean has not been closed or nulled out.

To confirm that this is the problem, look for an exception stack in the JVM log for the EJB Container which hosts the enterprise bean, which looks similar to: 

[time EDT] <ThreadID> StatefulPassi W CNTR0001W: A Stateful SessionBean could not be passivated: StatefulBeanO(BeanId(XXX#YYY.jar#ZZZZ, <ThreadID>), state = PASSIVATING) com.ibm.ejs.container.passivator.StatefulPassivator@<ThreadID>
java.io.NotSerializableException: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection 
 at java.io.ObjectOutputStream.outputObject((Compiled Code)) 
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code)) 
 at java.io.ObjectOutputStream.outputClassFields((Compiled Code)) 
 at java.io.ObjectOutputStream.defaultWriteObject((Compiled Code)) 
 at java.io.ObjectOutputStream.outputObject((Compiled Code)) 
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code)) 
 at com.ibm.ejs.container.passivator.StatefulPassivator.passivate((Compiled Code)) 
 at com.ibm.ejs.container.StatefulBeanO.passivate((Compiled Code) 
 at com.ibm.ejs.container.activator.StatefulASActivationStrategy.atUnitOfWorkEnd((Compiled Code)) 
 at com.ibm.ejs.container.activator.Activator.unitOfWorkEnd((Compiled Code)) 
 at com.ibm.ejs.container.ContainerAS.afterCompletion((Compiled Code)

where XXX,YYY,ZZZ is the Bean's name, and <ThreadID> is the thread ID for that run.

To correct this problem, the application must close all connections and set the reference to null for all connections. Typically this is done in the ejbPassivate() method of the bean. See the enterprise bean specification mandating this requirement, specifically section 7.4 in the EJB specification version 2.0. Also, note that the bean must be coded to reacquire these connections when the bean is reactivated. Otherwise, there will be NullPointerExceptions when the application tries to reuse the connections.

 

Symptom: org.omg.CORBA.BAD_PARAM: Servant is not of the expected type. minor code: 4942F21E completed: No

This error can be returned to a client program when the program attempts to execute an EJB method.

Typically this is caused by a mismatch between the interface definition and implementation of the client and server installations, respectively.

Another possible cause is when an appserver is set up to use a SINGLE class loading scheme. If an application is uninstalled while the application server remains active, the classes of the uninstalled application are still class-loaded in the application server. If you change the application, and redeploy and reinstall it on the application server, the previously loaded classes are now back level. The back level classes cause a code version mismatch between the client and the server.

To correct this problem:

  1. Change the appserver class loading scheme to <b>MULTIPLE</b>.
  2. Stop and restart the appserver and try the operation again.
  3. Make sure the client and server code version are the same.

Troubleshooting by component: what is not working?

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.