Search the FirstSpirit Knowledge Base
Hallo Community,
bei dem Versuch, etwas via FS Integration in die Oracle 11 Datenbank zu schreiben, bekommen wir folgende Meldung:
Error 500: Create a new entity with a release session isn't supported
Die DB hat folgende Konfiguration im Integration Modul: kein Serverseitiges Caching nutzen, keinen Freigabestand nutzen, Schemadaten in die DB synchronisieren.
Woran kann das liegen und was bedeutet in diesem Kontext "release session"?
Viele Grüße,
C. Klingbeil
Die Fehlermeldung besagt, dass eine Session benutzt wurde, die auf dem Freigabestand arbeitet. Damit können keine Datensätze angelegt werden. Sie sollten also noch mal prüfen, ob die Einstellungen korrekt sind und ob diese auch auf das Livesystem ausgerollt wurden.
Schön zu wissen, dass wir mit unserer Vermutung Recht hatten. Es spricht jedoch gegen diese Fehlerursache, dass in der fsweb.xml auf dem Websphere release= false steht. In der schemata.xml steht release=true. Kann daher das Problem kommen? Und welche xml wird von Integration genutzt? Ich dachte die fsweb.xml. Und die schemata.xml nutzt Personalisation. Richtig?
Noch weitere Erkenntnise aus unseren Tests auf 4.2R4:
Wird in dem Modul Integration ein Schema angelegt, das den gleichen Referenznamen wie das FS DB Schema mit Freigabestand hat, und greift das Modul Personalisation auf das gleiche Schema zu, passiert folgendes:
schema.xml --> release=true
fsweb.xml --> release=false
schemaname.schema.xsd --> existiert nur 1x und beinhaltet den Release-Stand
Fehler: Create a new entity with a release session isn't supported
Abhilfe schafft das Ändern des Schemanamens im Modul Integration. Danach existieren 2 ...schema.xsd Dateien. (Der Fehler ist aber immer noch nicht weg.) Jedoch ist uns aufgefallen, dass die Änderungen nur dann vollständig wirksam sind, wenn alle Module einmal gelöscht, der Server aktualisiert und danach die Konfigurationen erneut durchgeführt werden. Interessanter Weise ist die Konfiguration noch vorhanden, wenn das Modul im Projekt gelöscht (mit OK bestätigt) und wieder hinzugefügt wird. Ist das Verhalten so gewünscht?
Carola Klingbeil schrieb:
Abhilfe schafft das Ändern des Schemanamens im Modul Integration. Danach existieren 2 ...schema.xsd Dateien. (Der Fehler ist aber immer noch nicht weg.)
Welches Problem beheben zwei Schemata und welches Problem besteht danach noch?
Carola Klingbeil schrieb:
Jedoch ist uns aufgefallen, dass die Änderungen nur dann vollständig wirksam sind, wenn alle Module einmal gelöscht, der Server aktualisiert und danach die Konfigurationen erneut durchgeführt werden. Interessanter Weise ist die Konfiguration noch vorhanden, wenn das Modul im Projekt gelöscht (mit OK bestätigt) und wieder hinzugefügt wird. Ist das Verhalten so gewünscht?
Das sollte nicht so sein und ist ein Fall für unseren Helpdesk. Wichtige Informationen wären:
So... Der Fehler ist gefunden. Der Oracle JDBC Treiber hat auf dem FirstSpirit Server in der server/lib gefehlt. Die Frage ist nun, warum das Modul für den Oracle JDBC Treiber diesen nicht auf dem FirstSpirit Server ablegt. Bei den WebServern wird der Treiber korrekt hinzugefügt. Die Datenbankverbindung in FirstSpirit funktionierte auch korrekt. Nur Integration / Personalisation haben nicht ohne die jar in der server/lib funktioniert. Muss man also den Treiber wirklich von Hand dem FS Server hinzufügen? Kann das nicht das JDBC Modul machen?
FirstSpirit Version: 4.2R4.432
Systeme: Vorschau/Staging (verhalten sich beide ähnlich fehlerhaft, insbesondere Caching der Konfiguration)
WebAppServer: WebSphere 7
Sieht ihr JDBC-Modul denn die Verwendung in Webapplikationen vor? Siehe dazu die aktuellen Releasenotes, Kapitel 5.1.
Bitte wenden Sie sich damit an unseren Helpdesk, wahrscheinlich macht es Sinn gemeinsam auf das System zu schauen.