Tipps zur Fehlerbehebung bei Zugriffsarten
Im Folgenden werden einige häufig gestellten Fragen in Zusammenhang mit Zugriffsarten (Access Intents) beantwortet.
Fehler bei der Oracle-Datenbank, wenn keine Zugriffsrichtlinien angewendet werden
Es wurden keine Richtlinien für Zugriffsarten angewendet, und die Anwendung wird mit einer DB2-Datenbank ausgeführt, aber die Anwendung scheitert mit der folgenden Nachricht com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1001E: Eine derartige DataAccessSpec ist nicht vorhanden: FindAllCustomers. Der Back-End-Datenspeicher unterstützt nicht die SQL-Anweisung, die von der folgenden Zugriffsart benötigt wird: (pessimistic update-weakestLockAtLoad)(collections: transaction/25) (resource manager prefetch: 0) (AccessIntentImpl@d23690a).
Wurden keine Zugriffsarten konfiguriert, erfolgt der Zugriff auf alle Daten über die Standardzugriffsartsrichtlinie (wsPessimisticUpdate-WeakestLockAtLoad). In DB2 ist "share" (gemeinsame Nutzung) die schwächste Sperre. In Oracle-Datenbanken ist die Sperre mit den geringsten Einschränkungen eine Aktualisierungssperre, d. h., dass die SQL-Abfrage die Klausel FOR UPDATE enthalten muss. Wenden Sie eine Richtlinie für Zugriffsarten an, die Optimistic Concurrency unterstützt, um dieses Problem zu vermeiden.
Beim Aufruf einer Finder-Methode wird zur Laufzeit eine Ausnahme vom Typ "InconsistentAccessIntentException" angezeigt
Das kann geschehen, wenn Sie Richtlinien für Zugriffsarten für die Methodenebene verwenden, um das Laden einer Bean-Instanz eingehender zu steuern. Diese Ausnahme zeigt an, dass die Entity-Bean zuvor in derselben Transaktion geladen wurde. Das kann geschehen, wenn Sie eine multifinder-Methode, die die Bean-Instanz mit angewendeter Richtlinie für Zugriffsarten X zurückgegeben hat, aufgerufen haben. Sie versuchen jetzt, die zweite Bean erneut zu laden, indem Sie deren Methode "findByPrimaryKey" mit der angewendetem Zugriffsart Y aufrufen. Auf beide Methoden muss dieselbe Richtlinie für Zugriffsarten angewendet werden.
Wenn die Entität in der Transaktion mit einer in einem Suchprogramm konfigurierten Richtlinie für Zugriffsarten geladen wurde, haben Sie möglicherweise eine CMR-accessor-Methode (Container-Managed Relationship) aufgerufen, die die Entity-Bean zurückgegeben hat, die laut Konfiguration mit der Standardzugriffsart dieser Entität geladen werden soll.
Zur Vermeidung dieses Problems müssen Sie sicherstellen, dass der Code eine Bean-Instanz in derselben Transaktion nicht zweimal mit unterschiedlichen Richtlinien für Zugriffsarten lädt. Verwenden Sie Zugriffsarten für die Methodenebene nur, wenn dies absolut erforderlich ist.
Bei einer containergesteuerten Beziehung zwischen zwei Beans wird eine Ausnahme des Typs "InconsistentAccessIntentException" angezeigt
In einer containergesteuerten Beziehung sind zwei Beans vorhanden. Die Methode "findByPrimaryKey" wird für die erste Bean, und dann wird die Methode "getBean2" aufgerufen. Anschließend wird eine CMR-Zugriffsmethode für die zurückgegebene Instanz aufgerufen, woraufhin eine Ausnahme vom Typ "InconsistentAccessIntentException" angezeigt wird.
Sie verwenden wahrscheinlich Read-Ahead. Durch das Laden der ersten Bean wurde die zweite Bean unter der Richtlinie für Zugriffsarten, die auf die Finder-Methode der ersten Bean angewendet wurde, geladen. Auf die CMR-Accessor-Methode, die von der ersten zur zweiten Bean übergeben wurde, wurde jedoch eine andere Richtlinie für Zugriffsarten angewendet. CMR-Accessor-Methoden sind im Grunde verdeckte Finder-Methoden. Die Laufzeitumgebung verhält sich so, als ob Sie versuchen, die Zugriffsart für eine Instanz, die Sie bereits über den persistenten Speicher gelesen haben, zu ändern.
Zur Vermeidung dieses Problems werden Beans, die in einem Read-Ahead-Hint konfiguriert sind, mit derselben Richtlinie für Zugriffsarten geladen wie die Bean, auf die der Read-Ahead-Hint angewendet wird.
Eine Bean mit einer Eins-zu-viele-Beziehung zu einer zweiten Bean löst einen Fehler aus
Eine Bean mit einer Eins-zu-viele-Beziehung zu einer zweiten Bean löst einen Fehler vom Typ "UpdateCannotProceedWithIntegrityException" aus, wenn eine Instanz der zweiten Bean der Sammlung der ersten Bean hinzugefügt wird.
Eine Bean mit einer Eins-zu-viele-Beziehung zu einer zweiten Bean löst einen Fehler vom Typ "UpdateCannotProceedWithIntegrityException" aus, wenn eine Instanz der zweiten Bean der Sammlung der ersten Bean hinzugefügt wird. Für die erste Bean wurde eine Zugriffsrichtlinie vom Typ "pessimistic-update" angewendet.
Für die zweite Bean wurde eine Zugriffsrichtlinie vom Typ "Read" angewendet. Wenn Sie die zweite Bean zur Objektgruppe der ersten Bean hinzufügen, aktualisieren Sie nicht den Status der ersten Bean, Sie führen eine implizite Statusänderung für die zweite Bean durch. Die zweite Bean enthält für die erste Bean einen fremden Schlüssel, der geändert wird.
Zur Vermeidung dieses Problems müssen Sie sich vergewissern, dass für beide Endpunkte der Beziehung eine Zugriffsrichtlinie vom Typ "update" angewendet wurde, wenn Sie die Beziehung zur Laufzeit ändern möchten.