Commit oder Rollback, wenn nur gelesen wird

[hoika]

Hallo #,

jede DB-Aktion findet ja im Rahmen einer Transaktion statt,
wenn ich keine selber starte, erfolgt das automatisch.

Ich erinnere mich, mal gelesen zu haben, dass ein Rollback
in der DB schneller geht als ein Commit,
falls keine Daten geändert worden sind.
Ich meine hier speziell Firebird (MGA).

Greife ich also nur lesend zu,
nimmt man dann ein Rollback ??

Delphi-Quellcode:

Transe.StartTransaction;
try
  Select
finally
  Transe.RollBack;
end;

oder Commit

Transe.StartTransaction;
try
  Select
finally
  Transe.Commit;
end;

Heiko

[Lemmy]

Hi,

ich wäre mit einer generellen Antwort vorsichtig....

Vermutlich dürfte es keine Probleme machen, was aber wenn Du einen Select auf eine StoredProcedure machst, die irgend was in die DB schreibt? Dann wunderst Du dich warum deine SP nicht so funktioniert wie du erwartest.

Ein Rollback würde ich nur dann machen, wenn wirklich etwas schief gegangen ist - ansonsten ein Commit.

Grüße
Lemmy

[hoika]

Hallo,

schon klar,
ich sagte aber ausdrücklich select (ohne SP).

Ich benutze das start/select/commit an vielen Stellen.

Die Frage war halt, ob ein Rollback schneller ist.


Heiko

[alex517]

Hallo,

Zitat:

Zitat von hoika

Ich erinnere mich, mal gelesen zu haben, dass ein Rollback
in der DB schneller geht als ein Commit,
falls keine Daten geändert worden sind.

Ich bin ziemlich sicher das es genau anders herum ist. Das Commit ist schneller,
da nach einem Rollback noch aufgeräumt werden muß.
Ich kann allerdings nicht mehr sagen wo ich das gelesen haben.

Zitat:

Zitat von Lemmy

Vermutlich dürfte es keine Probleme machen, was aber wenn Du einen Select auf eine StoredProcedure machst, die irgend was in die DB schreibt? Dann wunderst Du dich warum deine SP nicht so funktioniert wie du erwartest.

Um solche Überraschungen auszuschließen benutze ich für Lesen und Schreiben getrennte Tarnsaktionen.
Die Parameter der Lesetransaktion sind so eingestellt, dass damit nur gelesen und nicht geschrieben werden kann.

alex

[Lemmy]

Zitat:

Zitat von alex517

Ich bin ziemlich sicher das es genau anders herum ist. Das Commit ist schneller,

ich meine auch mal so was gehört/gelesen zu haben bin mir aber absolut nicht sicher. Wenn wirklich nur gelesen wird, dann sollte eigentlich auch nichts zum aufräumen da sein. Auf der anderen Seite - wenn viele andere schreibend auf die DB zugreifen....

Zitat:

Zitat von alex517

Um solche Überraschungen auszuschließen benutze ich für Lesen und Schreiben getrennte Tarnsaktionen.
Die Parameter der Lesetransaktion sind so eingestellt, dass damit nur gelesen und nicht geschrieben werden kann.

darf ich dich kurz mal um 2 Infos bitten: 1. Welche Zugriffskomponenten, 2. die Einstellungen der Lese_Transaction... ich habe mich bisher nicht wirklich um die Einstellungen der Transaction-Komponenten gekümmert....

Grüße
Lemmy

[ManuelR]

Hallo,

mir ist nicht klar was bei einer Leseoperation "rollBacked" bzw. "commited" werden soll.
Es wurde ja nichts verändert.

ein Transaktionen nur braucht man nur
wenn Änderungen durchgeführt werden, damit
die Daten konsistent bleiben.
Wenn alle Änderungen durchgeführt werden konnten wird
mit einem Commit abgeschlossen ansonsten wird mit Rollback alles
wieder in den Ursprungszustand zurückversetzt.

Viele Grüsse

[hoika]

Hallo ManuelR,

Unsinn ! ;) (Tschulligung)

Jede Aktion findet im Kontext einer Transaktion statt,
um z.B. sicherzustellen, dass zweimaliges Select
(z.B. des gleichen Datensatzes) ímmer das gleiche ergibt,
auch wenn er von einer anderen Transaktion in der Zwischenzeit
geändert wurde (isolation level: repeatable read oder snapshot).

Wichtig ist das bei längeren Transaktionen,
z.B. Inventur.
Wenn z.B. ein

User1: Select * From Articles 100 Artikel anzeigt
User2: trägt einen neuen Artikel ein
User1: Select Count(*) From Articles ergibt trotzdem 100


Ich benutze beim Select manuelle Transaktionen,
weil das sehr bei mehreren Selects schneller ist,
also die von der (BDE, jaja) bereitsgestellten automatischen Transaktionen.

Bsp:
Ohne manuelle Transaktionen

Select * From bla1 1. Transaktion start/commit
Select * from bla2 2. Transaktion start/commit
Select * from bla3 3. Transaktion start/commit

mit manuellen Transaktionen
1. Transaktion Start
Select * From bla1
Select * from bla2
Select * from bla3
1. Transaktion Commit


Letzters ist in der Regel bei mir um Faktor 2-3 schneller.


Heiko

[alex517]

Zitat:

Zitat von ManuelR

ein Transaktionen nur braucht man nur
wenn Änderungen durchgeführt werden, damit
die Daten konsistent bleiben.

Abgesehen vom Zusammenfassen der Datenänderungen ist eine Transaktion
als Erstes die Art der Sicht auf die Daten. Also welche Daten sehe ich
im Laufe der Transaktion.
Dies wird den Isolationsgrad definiert (Read Committed, Snapshot, ...)

Deshalb wird auch das Lesen immer innerhalb einer Transaktion durchgeführt
auch wenn du selbst in deinem Programm explizit keine gestartet hast.

alex

p.s Heiko war schneller. :P

[Hansa]

Zitat:

Zitat von Lemmy

darf ich dich kurz mal um 2 Infos bitten: 1. Welche Zugriffskomponenten, 2. die Einstellungen der Lese_Transaction... ich habe mich bisher nicht wirklich um die Einstellungen der Transaction-Komponenten gekümmert....

Glaube er verwendet auch FIBPlus, so wie ich. Aber ohne Gewähr. Alex ist schlau. :mrgreen: Die Einstellungen der Transaktionen sind wichtig. Wer damit hantiert, der soll sich mal da die 4-teilige Artikelserie über Transaktionen ansehen.

[Bernhard Geyer]

Zitat:

Zitat von hoika

Unsinn ! ;) (Tschulligung)

Jede Aktion findet im Kontext einer Transaktion statt,
um z.B. sicherzustellen, dass zweimaliges Select ...

...

User1: Select * From Articles 100 Artikel anzeigt
User2: trägt einen neuen Artikel ein
User1: Select Count(*) From Articles ergibt trotzdem 100

Da war aus deinem ersten Post nicht zu ersehen das du mehrere Select's benötigst. Für einen einzelnes Select wäre die Transaktion unnötig.