"Gespeicherte Prozedur 'xxx' kann nur in unchained transaction-Modus." angezeigt, wenn der Aufruf einer Prozedur aus einer DataSource, die in einem EJB-Kontext

Wir haben eine Datenbank in Sybase, das wir den Zugriff aus einem Java-server.

Zugriff auf die DB gemacht wurde, direkt durch die Sybase-Treiber, mit DriverManager. Es war richtig, wir waren in der Lage, unsere gespeicherten Prozeduren.

Kürzlich haben wir die Migration zu einem application server (JBoss 5), und die Aufrufe der Datenbank werden nun durch einen JNDI-Anschluss, der mit einem DataSource:

Properties ppt = new Properties();
ppt.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
ppt.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
ppt.put("java.naming.provider.url", "jdbc/sybase");

InitialContext ctx = new InitialContext(ppt);
DataSource ds = (DataSource) ctx.lookup(AConfig.getInstance().getDatasourceJndiName());

Connection conn = ds.getConnection();

(Die DataSource konfiguriert ist, mit den Grundeinstellungen, aus der JBoss Beispiel)

Jedoch, in dieser Einstellung, mehrere Verfahren sind nicht mit diesem Fehler:

"Gespeicherte Prozedur" * * ' ausgeführt werden kann
nur in unchained Transaktion-Modus".

oder diese Art, auf andere Fälle (mit der fehlerhaften Befehl ändern):

TRUNCATE TABLE-Befehl nicht erlaubt
innerhalb von multi-statement transaction

Von dem, was ich gefunden im Internet, es sieht aus wie etwas in der JBoss oder der connector ist die Eröffnung einer Transaktion selbst, verursacht diese Fehler. Als solche, die vielfältigen Lösungen, die ich finden konnte, für diese speziellen Probleme zu lokalisieren, und wie es scheint, ein größeres Problem.

Gibt es eine Möglichkeit zu verhindern, dass dieses Verhalten (unter der Annahme, dass dies das eigentliche problem)?

Mein wissen in diesem Gebiet ist Recht Dünn, das ist mir neu. Als solche gibt es wahrscheinlich wichtige details fehlen, um diese Beschreibung. Bitte zeigen Sie mir, wie kann ich verbessern, diese Frage, welche Angaben kann ich noch hinzufügen, wenn nötig.

Was verwenden Sie für das Transaktions-management? Ich nehme an, Sie sind Initiierung einer Transaktion aus einer stateless session bean? Diese Meldung tritt in der Regel wegen einer Dritten Einstellung ein auto-commit-Eigenschaft und/oder der SET-VERKETTETE-Einstellung auf der DB
die datasource initialisiert wird, in ein init-servlet und ruft nach sind aus stateless beans in der Tat. Ich nicht sehen, aber was können diese Eigenschaften, das ist, warum ich davon ausgegangen, es war eine Einstellung in der JBoss. Ich sehe keine andere "Dritte Partei" in diesem Kontext.
Ich würde dringend empfehlen, verändern Sie Ihre code/Architektur, so dass Sie können nutzen Sie die macht der JBoss-connection-pooling -, Daten-Quellen, etc. Die eigentliche code-änderung relativ klein (es ist immer noch ein JNDI-lookup), und Sie werden in der Lage sein zu definieren, ob Sie mit 2-phase XA, lokale oder gar keine Transaktion datasources (definieren Sie diese in der *-ds.xml Datei). Siehe community.jboss.org/wiki/configdatasources für einen Ausgangspunkt. Sie wahrscheinlich auch müssen dann (via EJB3 annotations ich vermute) Haken in die Jboss - Txn-manager.
Sie zeigen mich in die richtige Richtung, danke. In der Tat, ein Teil des Problems ist, dass dies über die Portierung einer bestehenden Anwendung, mit einer Menge von business-code in Prozeduren. Transaktionen sind derzeit verwaltet die Verfahren direkt, das ist, warum mit local-tx ist nicht geeignet, Konflikte mit ihm. Der Wechsel zu no-tx (vorerst zumindest), scheint zu gehen in die richtige Richtung, aber einige Probleme bleiben. Ich werde aktualisieren, wenn ich etwas konkreteres zu schreiben.

InformationsquelleAutor Gnoupi | 2010-10-06

1

Das ist nicht korrekt.

Sicherlich Blick auf das größere Bild. Aber es ist ein noch größeres Bild.

Application server oder nicht, ist nicht das problem. Einstellungen in JBoss vs die Vorherige app (Java -) server ist das problem. Ihre Programmierer haben richtig sichergestellt werden, dass Ihre gespeicherte Prozeduren ausführen, wahre Geschäfte, und Sie sind geschützt, von der subversion durch externe Einrichtungen (alle aufrufende gespeicherte Prozedur oder app-server). Wenn Sie das getan haben, dann werden diese sprocs von alle app-server.

"Refactoring" ist für die MS-Welt, es ist nicht erforderlich alle in der Sybase-oder Relationalen Welt. Wenn Sie ändern die sprocs zu entfernen, die enge Kontrolle der Vorgänge, die Unternehmen darunter leiden: Verlust der Integrität von Daten; Verlust der referenziellen Integrität; lost updates; doppelte Transaktionen; etc. Wenn Sie gehen, um zu untergraben die sprocs, oder entfernen Sie die Transaktion Kontrolle (im Gegensatz zum "umgestalten"), werden Sie gewarnt, dass die Folge ist enorm.

Klar, JBoss wird standardmäßig entweder oder SET AUTOCOMMIT GEKETTET (weil viele Menschen nicht schreiben, wahr-Transaktionen, und dies sind die Standardwerte für MS SQL ), und Ihre bisherige Java (app) server haben das nicht.

Zweite, ODBC ist sehr langsam im Vergleich mit einer direkten Verbindung, so dass, wenn Sie nicht gefühlt haben es doch bewusst sein, dass Sie, sehr bald. Datasources sind nicht "umgesetzt", Sie sind lediglich konfiguriert (dauert ein paar Minuten). Verwenden Sie ODBC oder JDBC. Es ist eine Fettschicht zwischen, und stellt ein kleiner Puffer zwischen dem Programm und der Datenbank ein, und gibt natürlich alle die Kontrolle, die Sie hatte und genossen vor, als hätte man die native Anbindung. Ich habe gesehen, dass es so viel wie zwölf mal langsamer.

Dritte, hat nicht jeder, überprüfen Sie die JBoss-aus (ein), bevor Sie es auswählen, für die native Sybase-Konnektivität (im Gegensatz zu generischen MS-orientiert), (b) während der Durchführung und (c) während der Prüfung ?

Wenn Ihre verbindungen sind das problem, sicherlich, dann einfach befassen sich mit der Verbindung problem, und implementieren Sie die Verbindungs-pooling (Java-und Sybase-Bibliotheken dafür), eher als die Verringerung der Qualität und Leistung Ihrer Anwendung, sowie die Konsistenz (das ist die C-SÄURE) der Datenbank.

EAServer (Sybase) und WebShpere (IBM) haben solche Probleme nicht; Sie führen die Verbindungs-pooling; und Sie nutzen die native Verbindung zum ASE (keine ODBC-oder JDBC erforderlich).

Vielen Dank für diese sehr ausführliche Beschreibung. Wir hatten eigentlich die Verbindungs-pooling in Java implementiert ist, korrekt funktioniert, in der bestehenden Anwendung. Als ich sagte in meiner Antwort, wir sind zurück, um es zu benutzen, selbst im Kontext. Es basiert auf der Sybase-Treiber, so werden wir wahrscheinlich nur halten Sie es, wie Sie vorschlagen, ein performance-Problem, das auftreten würde, mit dieser datasource von JBoss. Ihre Antwort ist die beschreibend ist für meine Frage, ich werde wechseln "akzeptiert" markieren. Danke, wieder!
AUTOCOMMIT ist das gleiche wie SET CHAINED OFF und dem gegenüber SET CHAINED ON so Ihre Aussage "JBoss wird standardmäßig entweder oder SET AUTOCOMMIT GEKETTET" ist verwirrend. Ich denke Sie sollten konsequent entweder autocommit-Terminologie ("autocommit" / "nicht-autocommit") oder angekettet Terminologie ("chained off" / "gekettet" bzw.)

InformationsquelleAutor PerformanceDBA
5

Offenbar in Sybase gespeicherte Prozeduren erstellt werden, entweder in einer verketteten oder unchained-Modus.

Wenn Sie diese Fehlermeldung bekommen, es bedeutet, dass Ihr SP wurde als Unchained. Diese Java-line conn.setAutoCommit(false); übersetzt "gekettet".

Können Sie die Ausführung dieses Sybase SP, Liste der Transaktionsmodus alle Ihre SP ' s in die DB:
```
sp_procxmode
```
So benötigen Sie zum aufrufen Ihrer SP auf den unchained-Modus und explizit zu verwenden, erstellen transaction, commit transaction und rollback transaction.

Zum Beispiel:
```
insert into publishers 
    values ("9906", null, null, null)
begin transaction
delete from publishers where pub_id = "9906"
rollback transaction
```
Finden Sie mit diesem link.

InformationsquelleAutor Miguel Ortega
1

Dies könnte helfen: http://forum.springsource.org/showthread.php?t=49398, 'Holly' zu haben scheint, gelöst ist das problem

Danke für deine Hilfe, du hast mir die Zeiger, um herauszufinden, das eigentliche problem, das größer war als diese Nachrichten.
Sie sind herzlich willkommen!

InformationsquelleAutor Martijn Verburg

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.