WebSphere Application Server Version 6.1 Feature Pack for Web Services
             Operating Systems: AIX, HP-UX, i5/OS, Linux, Solaris, Windows, z/OS

             Personalize the table of contents and search results

Enterprise bean cannot be accessed from a servlet, a JSP file, a stand-alone program, or another client

This article provides troubleshooting tips for problems related to accessing enterprise beans.

What kind of error are you seeing?

[AIX HP-UX Linux Solaris Windows] [i5/OS] If the client is remote to the enterprise bean, which means, running in a different application server or as a stand-alone client, browse the JVM logs of the application server hosting the enterprise bean as well as log files of the client.

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

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 addressed in the code, according to the EJB 2.1 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 begins with "com.ibm...", then search for the exception name within the information center, and in the online help as described below. If "exception name" indicates an exception thrown by your application, contact the application developer to determine the cause.

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

A possible reason for this 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 a "local" interface method of the enterprise bean . If access worked in a development environment but not when deployed to WebSphere Application Server, for example, it might be that the enterprise bean and its client were in the same JVM in development, but are in separate processes after deployment.

To resolve this problem, contact the developer of the enterprise bean and determine whether the client call is to a method in the local interface for the enterprise bean. If so, have the client code changed to call a remote interface method, or to 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:.

BeanNotReentrantException is thrown

This problem can occur because client code (typically a servlet or JSP file) is attempting to call the same stateful SessionBean from two different client threads. This situation often results when 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. The application then has the client browser issue a new request to the servlet or JSP file before the previous request has completed.

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

CSITransactionRolledbackException / TransactionRolledbackException is thrown

[AIX HP-UX Linux Solaris Windows] [i5/OS] An enterprise bean container creates these high-level exceptions to indicate that an enterprise bean call could not successfully complete. When this exception is thrown, browse the JVM logs to determine the underlying cause.

[z/OS] An enterprise bean container creates these high-level exceptions to indicate that an enterprise bean call could not successfully complete. When this exception is thrown, browse the logs to determine the underlying cause.

Some possible causes include:
  • The enterprise bean might throw 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 creates 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 signature.
  • A transaction might attempt to do additional work after being placed in a "Marked Rollback", "RollingBack", or "RolledBack" state. Transactions cannot continue to do work after they are set to one of these states. This situation occurs because the transaction has timed out which, often occurs because of a database deadlock. Work with the application database management tools or administrator to determine whether database transactions called by the enterprise bean are timing out.
  • A transaction might fail on commit due to dangling work from local transactions. The local transaction encounters some "dangling work" during commit. When a local transactions encounters an "unresolved action" the default action is to "rollback". You can adjust this action to "commit" in an assembly tool. 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

This problem can occur because:
  • When the DataSource resource was configured, container managed persistence was not selected.
    • To confirm this problem, in the administrative console, browse the properties of the data source given in the NameNotFoundException. On the Configuration panel, look for a check box labeled Container Managed Persistence.
    • To correct this problem, select the check box for Container Managed Persistence.
  • If container managed persistence is selected, it is possible that the CMP DataSource could not be bound into the namespace.
    • [AIX HP-UX Linux Solaris Windows] [i5/OS] Look for additional naming warnings or errors in the status bar, and in the hosting application server JVM logs. Check any further naming-exception problems that you find by looking at the topic Application access problems.
    • [z/OS] Look for additional naming warnings or errors in the status bar, and in the hosting application server logs. Check any further naming-exception problems that you find by looking at the topic Application access problems.

Symptom:CNTR0001W: A Stateful SessionBean could not be passivated

This error can occur when a Connection object used in the bean is not closed or nulled out.

[AIX HP-UX Linux Solaris Windows] [i5/OS] To confirm this is the problem, look for an exception stack in the JVM log for the EJB container that hosts the enterprise bean, and 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.
[z/OS] To confirm this is the problem, look for an exception stack in the logs for the EJB container that hosts the enterprise bean, and looks similar to:
StatefulPassi W CNTR0001W: 
A Stateful SessionBean could not be passivated: StatefulBeanO
(BeanId(XXX#YYY.jar#ZZZZ), 
state = PASSIVATING) 
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.

To correct this problem, the application must close all connections and set the reference to null for all connections. Typically this activity 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.1. Also, note that the bean must have code to reacquire these connections when the bean is reactivated. Otherwise, there are NullPointerExceptions when the application tries to reuse the connections.




Related tasks
Assembling EJB modules
Reference topic    

Terms of Use | Feedback

Last updated: Nov 25, 2008 2:35:59 AM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/rtrb_ejbaccessprobs.html