Oracle-ODBC Treiber bockt

a9bejo

Zitat von maciek

Bei Oracle kann aber ein read Zugriff in der Regel nicht von einem modifying Zugriff "geblockt" werden.

Stimmt, aber umgekehrt ist es moeglich, also das der modifier vom read geblocked wird. Ein DELETE waherend einem READ wird ein Transactionopitmizer wohl so auswerten muessen, dass das DELETE erst abgeschlossen werden kann, nachdem das READ abgeschlossen ist. Man kann Daten natuerlich zwischenspeichern, aber eben nicht vollstaendig. Und fuer JDBC ist der READ Befehl eben erst mit dem Schliessen des ResultSet beendet.

Zitat von Java Girl

Danke, ich werde das einmal ausprobieren, geht aber erst frühestens am Montag, dann werde ich mich melden.

Bitte nicht drauf vergessen, Ich bin schon gespannt.

java-girl

Zitat von java-girl

Danke, ich werde das einmal ausprobieren, geht aber erst frühestens am Montag, dann werde ich mich melden.

So...jetzt habe ich mein Programm gestartet, selbe Voraussetzungen wie am Mittwoch und siehe da - es funktioniert!
Der einzige Unterschied war dass ich am Mittwoch beim Start des Programmes eine SQL-Commandline offen hatte...heute nicht...

Ringding

Ja das muss jeder mal lernen ;). Datenbanktransaktionen sind einfach nicht dafür gedacht, lange offen zu bleiben.

java-girl

Zitat von Ringding

Ja das muss jeder mal lernen ;). Datenbanktransaktionen sind einfach nicht dafür gedacht, lange offen zu bleiben.

Was soll denn das jetzt bedeuten?

Ringding

Ganz einfach, Datenbanktransaktionen sollen immer so verwendet werden:

1. Transaktion starten
2. Daten ändern (oder lesen)
3. Commit (oder rollback)

Und zwar so schnell wie möglich hintereinander.

Du hast dich nicht daran gehalten (dein Commandline-Client hatte ne Transaktion offen), daher hast du Probleme bekommen.

java-girl

Zitat von Ringding

Und zwar so schnell wie möglich hintereinander.

Das ist ja sowas von sch*** egal. Es geht dabei ja nur darum dass eine Transaktion die aus mehreren Teilen besteht nicht unterbrochen wird. Aber sonst können Stunden zwischen einem SELECT und einem zweiten vergehen.

Außerdem...wenn ich auf der CommandLine und im Apex angemeldet bin dann gibt es auch keinerlei Probleme. Und bei MySQL natürlich auch.
Also ist eindeutig dieser mistige Treiber schuld und nicht mein Vorgehen...
Im Übrigen: schon mal etwas von Autocommit gehört?

Paulchen

Zitat von java-girl

Das ist ja sowas von sch*** egal. Es geht dabei ja nur darum dass eine Transaktion die aus mehreren Teilen besteht nicht unterbrochen wird. Aber sonst können Stunden zwischen einem SELECT und einem zweiten vergehen.

Bei Oracle kann das schon Probleme machen. Es werden nämlich durch eine Transaktion Sperren auf Objekte in der Datenbank angefordert, die Zugriffe durch andere Transaktionen auf dieselben Objekte verhindern. Diese anderen Transaktionen müssen dann warten, bis die gesperrten Objekte am Ende der ersten Transaktion (Commit oder Rollback) wieder freigegeben werden.

Atomarität ist nämlich nicht die einzige Eigenschaft von Transaktionen. -> ACID-Prinzip.

Zitat von java-girl

Und bei MySQL natürlich auch.

Du kannst nicht von einem RDBMS auf ein anderes schließen, vielleicht arbeiten die ja anders. Vor allem MySQL fehlen zahlreiche Features - soviel ich weiß gibt's da gar keine Transaktionsverwaltung.

java-girl

Zitat von Paulchen

Du kannst nicht von einem RDBMS auf ein anderes schließen, vielleicht arbeiten die ja anders. Vor allem MySQL fehlen zahlreiche Features - soviel ich weiß gibt's da gar keine Transaktionsverwaltung.

Es geht nicht darum, es geht darum, dass der Treiber seltsam reagiert und dass der Treiber bzw. Oracle selbst nicht fähig ist, eine vernünftige Fehlermeldung gibt. Und wie gesagt - CommandLine & Apex in Kombination funktioniert definitiv - hab' ich schon öfters so gehabt. Und wenn das schon nicht sein soll, dann sollte wenigstens von Oracle aus verhindert werden, dass sich derselbe Benutzer öfters anmeldet.

Jetzt mitmachen!