Oracle-ODBC Treiber bockt

    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.

    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...

    There's no better place than 127.0.0.1!

    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.

    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?

    There's no better place than 127.0.0.1!

    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.

    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.

    There's no better place than 127.0.0.1!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden