Kein Zugriff auf Enterprise-Beans über ein Servlet, eine JSP-Datei, ein eigenständiges Programm oder einen anderen Client

Verwenden Sie die folgenden Fehlerbehebungstipps für Probleme, die sich auf den Zugriff auf Enterprise-Beans beziehen.

[AIX Solaris HP-UX Linux Windows][IBM i]Wenn der Client ein ferner Client der Enterprise-Bean ist, d. h. wenn der Client in einem anderen Anwendungsserver oder als eigenständiger Client ausgeführt wird, untersuchen Sie die JVM-Protokolle des Anwendungsservers, der die Enterprise-Bean bereitstellt, sowie die Protokolldateien des Clients.

[z/OS]Wenn der Client ein ferner Client der Enterprise-Bean ist, d. h. wenn der Client in einem anderen Anwendungsserver oder als eigenständiger Client ausgeführt wird, untersuchen Sie die Protokolle des Anwendungsservers, der die Enterprise-Bean bereitstellt, sowie die Protokolldateien des Clients.

[AIX Solaris HP-UX Linux Windows][IBM i]Ist keines der beschriebenen Probleme mit Ihrem vergleichbar oder sollten Sie anhand der bereitgestellten Informationen das Problem nicht lösen können, gehen Sie wie folgt vor:
  1. Falls sich das Problem auf den Namensservice zu beziehen scheint, d. h. wird ein Fehler vom Typ "NameNotFoundException" oder eine Nachrichten-ID, die mit NMSV beginnt, angezeigt, finden Sie in den folgenden Abschnitten nähere Informationen:
  2. Prüfen Sie, ob der Fehler aufgezeichnet und dokumentiert wurde. Verwenden Sie dazu die Links im Abschnitt Fehlerdiagnose und -behebung: Lernmaterial.
Sollten Sie das Problem trotzdem nicht beheben können, lesen Sie den Artikel Hilfe von IBM zur Fehlerbehebung.

java.lang.NoSuchMethodError

Beim Versuch, eine Methode in einer Session-Bean aufzurufen, ist ein Fehler des Typs "java.lang.NoSuchMethodError" aufgetreten.

Im Folgenden sehen Sie ein Beispiel für diesen Typ von Fehler:
When trying to invoke the method xSLTStory4Session on a bean, a java.lang.NoSuchMethodError displayed.

CNTR0020E: EJB hat eine unerwartete (nicht deklarierte) Ausnahme beim Aufruf der Methode "xSLTStory4Session" für Bean "BeanId(ERWW_v8#XSLTStory4SessionEJB3.jar#XSLTStory4SessionFacadeBean, null) ausgelöst". 
Ausnahmedaten: java.lang.NoSuchMethodError: paysession/ejb3/PaySessionFacadeRemote.paySession(Ljava/lang/String;)Ljava/lang/String;

In diesem Fall gibt es mehrere Version der Schnittstelle "PaySessionFacadeRemote" in mehreren Modulen in der EAR-Datei. Ein dieser Schnittstellen enthält nicht die erwartete Methode.

Die Stubklasse wurde von der Laufzeitumgebung aus der ersten Version der Schnittstelle "PaySessionFacadeRemote" im Klassenpfad der EAR-Datei generiert. Dies war die falsche Version.

ObjectNotFoundException oder ObjectNotFoundLocalException beim Zugriff auf eine Stateful-Session-EJB

Eine mögliche Ursache für diesen Fehler ist, dass die Stateful-Session-Bean ein Zeitlimit überschritten hat und aus dem Container entfernt wurde. Dieses Ereignis muss gemäß der Spezifikation EJB Version 2.1 oder höher codiert werden.

Stack-Trace, der mit der Zeichenfolge "EJSContainer E Bean method threw exception [Name_der_Ausnahme]" beginnt, in JVM-Protokolldatei ermittelt.

Wenn der Name der Ausnahme eine Ausnahme anzeigt, die von einer IBM Klasse ausgelöst wurde, d. h., wenn die Klasse mit "com.ibm..." beginnt, suchen Sie in diesem Information Center und in der Onlinehilfefunktion nach dem Namen der Ausnahme. Wenn der Name der Ausnahme eine Ausnahme anzeigt, die von Ihrer Anwendung ausgelöst wurde, wenden Sie sich an den Anwendungsentwickler, um die mögliche Ursache festzustellen.

Fehler: javax.naming.NameNotFoundException: Name name wurde im Kontext "local" nicht gefunden

Ein möglicher Grund für diese Ausnahme ist, dass die Enterprise-Bean nicht lokal, d. h. nicht auf derselben JVM (Java Virtual Machine) oder auf demselben Anwendungsserver wie die Client-JSP, das Servlet, die Java-Anwendung oder eine andere Enterprise-Bean ausgeführt wird, der Aufruf sich jedoch auf eine lokale Schnittstellenmethode der Enterprise Bean bezieht. Wenn der Zugriff in einer Entwicklungsumgebung, jedoch nicht in einer Implementierung in WebSphere Application Server möglich ist, kann das daran liegen, dass die Enterprise-Bean und deren Client sich während der Entwicklung auf derselben JVM, nach der Implementierung jedoch in separaten Prozessen befinden.

Wenden Sie sich zur Lösung dieses Problems an den Entwickler der Enterprise-Bean, und stellen Sie fest, ob der Clientaufruf an eine Methode in der lokalen Schnittstelle der Enterprise-Bean gerichtet ist. Wenn das der Fall ist, lassen Sie den Clientcode so ändern, dass eine ferne Schnittstellenmethode aufgerufen wird, oder leiten Sie die lokale Methode an die ferne Schnittstelle weiter.

Referenzen auf Enterprise-Beans mit lokalen Schnittstellen sind an einen lokalen Namespace des Serverprozesses mit dem URL-Schema local: gebunden. [AIX Solaris HP-UX Linux Windows][IBM i]Wenn Sie einen Speicherauszug eines "local:"-Server-Namespace abrufen möchten, verwenden Sie das Speicherauszugsdienstprogramm für Namespaces, das im Artikel "Beispiel: Das Speicherauszugsdienstprogramm für java:-, local: und server-Namespaces" beschrieben ist.

BeanNotReentrantException wird ausgelöst

Dieses Problem kann vom Clientcode ausgelöst werden (normalerweise von einem Servlet oder von einer JSP), der versucht, dieselbe Stateful-Session-Bean von zwei verschiedenen Client-Threads aufzurufen. Diese Situation tritt häufig ein, wenn eine Anwendung die Referenz auf die Stateful-Session-Bean in einer statischen Variable speichert, eine globale (statische) JSP-Variable verwendet, um auf die Referenz der Stateful-Session-Bean zu verweisen, oder die Referenz auf die Stateful-Session-Bean im Objekt der HTTP-Sitzung speichert. Dann veranlasst die Anwendung den Client-Browser, eine neue Anforderung an das Servlet oder die JSP abzusetzen, bevor die vorherige Anforderung abgeschlossen ist.

Wenn Sie dieses Problem lösen möchten, bitten Sie den Codeentwickler, den Code auf diese Bedingung zu überprüfen.

CSITransactionRolledbackException / TransactionRolledbackException wird ausgelöst

[AIX Solaris HP-UX Linux Windows][IBM i]Ein Enterprise-Bean-Container löst diese Ausnahmen der höheren Ebene aus, um anzuzeigen, dass der Aufruf einer Enterprise-Bean nicht durchgeführt werden konnte. Wenn diese Ausnahme ausgelöst wird, untersuchen Sie die JVM-Protokolle, um die eigentliche Ursache festzustellen.

[z/OS]Ein Enterprise-Bean-Container löst diese Ausnahmen der höheren Ebene aus, um anzuzeigen, dass der Aufruf einer Enterprise-Bean nicht durchgeführt werden konnte. Wenn diese Ausnahme ausgelöst wird, untersuchen Sie die Protokolle, um die eigentliche Ursache festzustellen.

Einige mögliche Ursachen sind:
  • Die Enterprise-Beans kann eine Ausnahme ausgelöst haben, die nicht im Rahmen dieser Methodensignatur deklariert worden ist. Der Container muss die Transaktion in diesem Fall zurücksetzen. Allgemeine Ursachen: Die Enterprise-Bean oder der Code, den sie aufruft, löst eine NullPointerException, eine ArrayIndexOutOfBoundsException oder eine andere Ausnahme der Java-Laufzeit aus oder eine BMP-Bean ermittelt einen JDBC-Fehler. Prüfen Sie den Enterprise-Bean-Code, um die zugrunde liegende Ausnahme aufzulösen, oder fügen Sie die Ausnahme zur Signatur der betroffenen Methode hinzu.
  • Eine Transaktion kann versuchen, weitere Aktionen auszuführen, nachdem sie in den Status "Marked Rollback", "RollingBack" oder"RolledBack" versetzt wurde. Transaktionen können, nachdem sie in einen dieser Status versetzt wurden, keine Aktionen mehr ausführen. Dieser Fehler tritt häufig auf, wenn die Transaktion ein Zeitlimit überschritten hat. In vielen Fällen ist eine Datenbanksperre der Grund für die Zeitlimitüberschreitung. Stellen Sie anhand der Datenbankverwaltungstools der Anwendung oder mithilfe des Administrators der Anwendung fest, ob Datenbanktransaktionen, die von der Enterprise-Bean aufgerufen wurden, ein Zeitlimit haben.
  • Eine Transaktion kann möglicherweise aufgrund hängender Arbeitsvorgänge von lokalen Transaktionen nicht festgeschrieben werden. Die lokale Transaktion stellt während der Commit-Operation fest, dass Arbeiten noch nicht erledigt sind. Wenn eine lokale Transaktion eine "nicht aufgelöste Aktion" ermittelt, wird standardmäßig ein Rollback durchgeführt. Sie können diese Aktion in einem Assembliertool in "Festschreiben" (Commit) ändern.

Der Versuch, ein EJB-Modul zu starten, scheitert mit der Ausnahme "javax.naming.NameNotFoundException dataSourceName_CMP"

Mögliche Fehlerursachen:
  • Bei der Konfiguration der Datenquellenressource wurde CMP (Container Managed Persistence) nicht ausgewählt.
    • Wenn Sie sich vergewissern möchten, dass dies die Ursache des Problems ist, durchsuchen Sie in der Administrationskonsole die Eigenschaften der in der Ausnahme "NameNotFoundException" angegebenen Datenquelle. In der Anzeige "Konfiguration" befindet sich ein Kontrollkästchen CMP (Container Managed Persistence).
    • Wählen Sie das Kontrollkästchen CMP aus, um den Fehler zu beheben.
  • Ist CMP ausgewählt, besteht die Möglichkeit, dass die CMP-Datenquelle nicht in den Namespace eingebunden werden konnte.
    • [AIX Solaris HP-UX Linux Windows][IBM i]Beobachten Sie, ob weitere Naming-Warnungen oder -Fehler in der Statusleiste und in den JVM-Protokollen des Hostanwendungsservers angezeigt werden. Prüfen Sie alle weiteren Naming-Ausnahmen im Abschnitt Probleme beim Anwendungszugriff.
    • [z/OS]Beobachten Sie, ob weitere Naming-Warnungen oder -Fehler in der Statusleiste und in den Protokollen des Hostanwendungsservers angezeigt werden. Prüfen Sie alle weiteren Naming-Ausnahmen im Abschnitt Probleme beim Anwendungszugriff.
[AIX Solaris HP-UX Linux Windows][IBM i]

Transaktion [Transaktions-ID] hat das zulässige Zeitlimit von 120 Sekunden beim Zugriff auf eine Enterprise-Bean überschritten

Dieser Fehler kann auftreten, wenn ein Client eine Transaktion für eine CMP- oder BMP-Enterprise-Bean ausführt.
  • Das Standardzeitlimit für Enterprise-Bean-Transaktionen ist 120 Sekunden. Nach Ablauf dieses Zeitraums hat die Transaktion das Zeitlimit überschritten, und die Verbindung wird geschlossen.
  • Wenn die Transaktion das angegebene Zeitlimit berechtigterweise überschreitet, klicken Sie auf Anwendungsserver verwalten Servername, wählen Sie die Seite Eigenschaften des Transaktionsservice aus, und sehen Sie sich die Eigenschaft Zeitlimit für Gesamtlebensdauer der Transaktion an. Erhöhen Sie diesen Wert, falls erforderlich, und speichern Sie die Konfiguration.
[z/OS]

Die Nachricht BBOT0003W wird ausgegeben.

Die Nachricht BBOT0003W weist auf das Überschreiten eines Transaktionszeitlimits hin. Das Überschreiten des Zeitlimits kann zur abnormalen Beendigung des Servants führen, in dem die Transaktion ausgeführt wurde.
  • Das Standardzeitlimit für Enterprise-Bean-Transaktionen ist 120 Sekunden. Nach Ablauf dieses Zeitraums hat die Transaktion das Zeitlimit überschritten, und die Verbindung wird geschlossen.
  • Wenn die Transaktion aus zulässigen Gründen das angegebene Zeitlimit überschreitet, führen Sie in der Administrationskonsole folgende Aktionen aus:
    1. Klicken Sie auf Anwendungsserver verwalten > Servername.
    2. Wählen Sie die Seite für die Eigenschaften des Transaktionsservice aus.
    3. Erhöhen Sie den Wert von Zeitlimit für Gesamtlebensdauer der Transaktion.
    4. Speichern Sie die Konfiguration.
    Anmerkung: z/OS verwendet den Wert, den Sie für Zeitlimit für Gesamtlebensdauer der Transaktion festlegen, als Standardzeitlimit für Transaktionen. Wenn Sie für diese Eigenschaft einen Wert festlegen, der das maximale Transaktionszeitlimit überschreitet, verwendet z/OS das maximale Transaktionszeitlimit als Standardwert.

Symptom:CNTR0001W: Eine Stateful-Session-Bean konnte nicht passiviert werden.

Dieser Fehler kann auftreten, wenn ein Verbindungsobjekt, das in der Bean verwendet wird, nicht geschlossen oder ungültig gemacht wurde.

[AIX Solaris HP-UX Linux Windows][IBM i]Wenn Sie sich vergewissern möchten, dass das tatsächlich die Fehlerursache ist, suchen Sie nach einem Ausnahme-Stack im JVM-Protokoll des EJB-Containers, in dem sich die Enterprise-Bean befindet. Der Stack sieht etwa wie folgt aus:
[time EDT] <ThreadID> StatefulPassi W CNTR0001W: 
Eine Stateful-Session-Bean konnte nicht passiviert werden: 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)
XXX,YYY,ZZZ steht für den Bean-Namen und <ThreadID> für die Thread-ID dieser Ausführung.
[z/OS]Wenn Sie sich vergewissern möchten, dass das tatsächlich die Fehlerursache ist, suchen Sie nach einem Ausnahme-Stack in den Protokollen des EJB-Containers, in dem sich die Enterprise-Bean befindet. Der Stack sieht etwa wie folgt aus:
StatefulPassi W CNTR0001W: 
Eine Stateful-Session-Bean konnte nicht passiviert werden: 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)
XXX,YYY,ZZZ steht für den Bean-Namen.

Zur Behebung dieses Fehlers muss die Anwendung alle Verbindungen schließen und die Referenz für alle Verbindungen auf null setzen. Gewöhnlich wird diese Aktivität in der Methode @ejbPassivate()" der Bean ausgeführt. Beachten Sie auch, dass die Bean codiert sein muss, damit diese Verbindungen bei der erneuten Aktivierung der Bean erneut abgerufen werden können. Ist das nicht der Fall, werden NullPointerExceptions ausgelöst, wenn die Anwendung versucht, die Verbindungen erneut zu verwenden.

[AIX Solaris HP-UX Linux Windows][IBM i]

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

Dieser Fehler kann an ein Clientprogramm zurückgegeben werden, wenn das Programm versucht, eine EJB-Methode auszuführen.

Gewöhnlich wird dieses Problem durch eine Diskrepanz zwischen Schnittstellendefinition und Implementierung der Client- und Serverinstallationen verursacht.

Er kann auch auftreten, wenn für den Anwendungsserver das Klassenladerschema "Einer" konfiguriert ist. Wenn eine Anwendung deinstalliert wird, während der Anwendungsserver aktiv ist, bleiben die Klassen der deinstallierten Anwendung weiterhin im Anwendungsserver geladen. Wenn Sie die Anwendung ändern und dann im Anwendungsserver erneut implementieren und installieren, sind die zuvor geladenen Klassen veraltet. Veraltete Klassen führen zu unterschiedlichen Codeversionen in Client und Server.

Gehen Sie wie folgt vor, um diesen Fehler zu beheben:
  1. Ändern Sie das Schema für das Laden der Anwendungsserverklassen in Mehrere.
  2. Stoppen Sie den Anwendungsserver, starten Sie ihn erneut, und wiederholen Sie dann die Operation.
  3. Stellen Sie sicher, dass die Codeversionen von Client und Server identisch sind.

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_ejbaccessprobs
Dateiname:rtrb_ejbaccessprobs.html