nicht angemeldet
Mehrere SQL-Abfolgen in einer Exception
Hallo Forum,
ich hatte in einem Hochschulprojekt oftmal den Fall, dass ich in einer Exception (Java) mehrere SQL-Anweisungen hintereinander stehen hatte.
(Ein Beispiel fällt mir leider nicht spontan ein. So etwas wie, Benutzer in die DB anlegen. Evtl. eine separate Tabelle noch mit einer Extraanweisung füllen, bzw. nochmals Daten abfragen und speichern. Wie auch immer)
Es kam nun manchmal vor, dass zwischen den SQL-Anweisungen eine Exception geworfen wurde, entweder weil im Javacode etwas schief gegangen ist oder die SQL-Anweisung davor einen Fehler ausgeworfen hat.
Mein Problem bestand dann darin, dass die SQL-Anweisungen vor dem Fehlerfall ausgeführt wurde, die nicht hätten passieren sollen, wenn insgesamt eine Exception ausgeworfen wird.
Ich hoffe, dass ich mein Problem verständlich darlegen könnte.
Meine Frage. Lautet mein Stichwort Transaktionen und Rollback oder geht man da anders vor.
Grüße
-
Hi,
yep, würd ich *ausschließlichst* mit Transaktionen machen.
BEGIN_TRANSACTION()
... doing ...
ON_FAIL
ROLLBACK()
ON_SUCCESS
COMMIT()Aufpassen dass die DB nicht AUTO_COMMIT = TRUE als Standardeinstellung nutzt, denn dann werden Transaktionen ignoriert.
Viel Erfolg!
-
Servus,
[...]
yep, würd ich *ausschließlichst* mit Transaktionen machen.
[...]Das würde ich unterschreiben, würde aber als Alternative zu datenbankgesteuerten Transaktionen mit JTA (und einer entsprechenden Implementierung) arbeiten. Dann bist Du vom DBMS unabhängig.
Schöne Grüße,
Peter
-
Hi,
vielen Dank Euch beiden. Ich lese mich dann auch diesbezüglich ein, wenn ich soweit bin, bzw. mit einem neuen Projekt starte.
Entweder dann gegen die JTA programmieren oder gleich Hibernate einsetzes, welches dann Transaktionen erlaubt.Sollte ich dann Probleme mit Hibernate oder allgemein Transationen/Comits usw. haben melde ich mich einfach nochmal :-)
Nochmals danke.
Viele Grüße
-
Servus,
[...]
Entweder dann gegen die JTA programmieren oder gleich Hibernate einsetzes, welches dann Transaktionen erlaubt.Wobei Hibernate dann ja wieder JTA verwendet. :)
Schöne Grüße,
Peter
-
Hi,
Entweder dann gegen die JTA programmieren oder gleich Hibernate einsetzes, welches dann Transaktionen erlaubt.
Wobei Hibernate dann ja wieder JTA verwendet. :)
Genau, deswegen auch ein "entweder oder" :-)
Grüße
-
-
-
moin,
Dann bist Du vom DBMS unabhängig.
das ist für mich wunschdenken und wäre so, als wenn ich eine applikation habe, die von der programmiersprache unabhängig ist.....
Ilja
-
Guten Morgen,
[...]
Dann bist Du vom DBMS unabhängig.
das ist für mich wunschdenken und wäre so, als wenn ich eine applikation habe, die von der programmiersprache unabhängig ist.....
Im Bezug auf das Transaktionsmanagement ist das kein Wunschdenken, sondern die Realität. Dass Unabhängigkeit vom DBMS im Bereich der Abfragen nur zu ca. 80% funktioniert, ist ein anderes Thema. Aber auch da würde ich jederzeit einem Persistenzmanager, der mir diese 80% ermöglicht, selbst geschriebenem SQL vorziehen. Für mich ist es ein Unterschied, ob ich die komplette Persistenzschicht einer Anwendung austausche, oder mir beim Wechsel der Datenbank Gedanken über die unschönen 20% machen muss, bei denen ich native Queries anstatt HQL/EJBQL/...QL verwendet habe.
Ich habe in mehreren Projekten gearbeitet, in denen auf verschiedenen Stages mit verschiedenen Datenbanken gearbeitet wurde, und das hat mit Persistenzmanager relativ problemfrei funktioniert. Ich hatte aber auch eine Hardcore Zweischichtanwendung auf Sybase-Basis, bei der die Datenbank auf DB2 umgestellt werden sollte. Und das sind die oben genannten 100%, die mir keinen Spaß machen. ;)Schöne Grüße,
Peter
-
Hi,
ohne Ilja geht ja fast kein Datenbankthread :-)JDBC ist ja (laut unserem Prof) auch eine Persisenzschicht, bzw. ein Dataabstraktionslayer. Man könne dann die Datenbank dahinter austauschen und die SQL-Befehle im Code lassen.
Wenn ich zum Beispiel aber von JDBC (mySQL) auf MSSQL wechsle, dann geht ja JDBC nicht, sondern bräuchte hier ja ODBC ne? D.h., ich müsste die SQL-Statements erneut anpassen.
Unser Prof. meinte dann, wenn wir keinen Datenabstraktionslayer nutzen wurden, müssten wir stur gegen die Datenbank programmierer, oder gegen den Treiber oder einen eigenen Treiber schreiben, weiß nicht mehr :-)
Wie würde das in etwa rein interessenhalber aussehen, im Endeffekt sind doch das dann auch SQL-Befehle oder nicht, was ich irgendwie rüberjagen muss, speziell für ein DBMS (Bsp. mySQL)Grüße
-
Servus,
[...]
ohne Ilja geht ja fast kein Datenbankthread :-)Ich denke, aufgrund seiner Kompetenz im Bereich DB ist das gut für die jeweiligen Threads.
[...]
JDBC ist ja (laut unserem Prof) auch eine Persisenzschicht, bzw. ein Dataabstraktionslayer. Man könne dann die Datenbank dahinter austauschen und die SQL-Befehle im Code lassen.Das stimmt. Allerdings werden bei SQL-Statements in der Regel sehr schnell DBMS-abhängige Erweiterungen verwendet (Beispiel Paging von Ergebnissen). Das kann man über einen über JDBC gelegten Abstraktionslayer (z.B. JPA) sehr schön abkapseln und in der jeweiligen Strategy für das konkrete Produkt (was dann aber zentral vom JPA-Provider gepflegt wird) verschieden implementieren.
Wenn ich zum Beispiel aber von JDBC (mySQL) auf MSSQL wechsle, dann geht ja JDBC nicht, sondern bräuchte hier ja ODBC ne? D.h., ich müsste die SQL-Statements erneut anpassen.
Wenn es "Standard"-SQL ist, geht das. Es gibt bestimmt auch für MSSQL einen JDBC-Treiber, oder?
[...]
Wie würde das in etwa rein interessenhalber aussehen, im Endeffekt sind doch das dann auch SQL-Befehle oder nicht, was ich irgendwie rüberjagen muss, speziell für ein DBMS (Bsp. mySQL)Das kommt auf den Treiber an. Ich habe noch nicht in die Implementierung von einem geschaut. Aber ich denke, in den meisten Fällen wird hier kein SQL, sondern ein bereits vorverarbeitetes Protokoll verwendet. Hier kommt es halt darauf an, welche Schnittstellen die Datenbank nach außen für einen solchen Treiber anbietet. Also irgendeine Art Kommunikation von außerhalb des Servers (in der Regel Netzwerk).
Schöne Grüße,
Peter
-
moin,
Aber ich denke, in den meisten Fällen wird hier kein SQL, sondern ein bereits vorverarbeitetes Protokoll verwendet. Hier kommt es halt darauf an, welche Schnittstellen die Datenbank nach außen für einen solchen Treiber anbietet.
in aller regel ist die schnittstelle zu einer datenbank SQL und somit sollte auch SQL dort ankommen.
Ilja
-
Guten Morgen,
[...]
in aller regel ist die schnittstelle zu einer datenbank SQL und somit sollte auch SQL dort ankommen.Weißt Du hier aus der Datenbanktreiberprogrammierung, dass dort auch intern mit SQL gearbeitet wird, d.h. hast Du schon Quellcode eines solchen / mehrerer solcher Treiber gesehen oder entwickelt? Ich stelle mir hier ein effizienteres Kommunikationsprotokoll (evtl. binär) vor. Aber wie gesagt: ich habe noch keine Datenbanktreiber auf tiefster Ebene programmiert oder den Quellcode dazu gesehen.
Schöne Grüße,
Peter
-
Hi,
ich wollte mich noch kurz bei euch beiden Bedanken für die Tipps :-)
Grüße
-
-
-
-
-
-
-
-