[PEAR] Transaction Emulation
[PEAR] Transaction Emulation
am 26.02.2005 01:25:22 von Niels Braczek
Moin moin,
sieht jemand eine realistische Chance, den DB-Abstraktionslayern
DB/DBA/MDB/MDB2 (bzw. einem davon) beizubringen, Transaktionen auf
MyISAM-Tabellen zu emulieren? Wenn ja: wie? Intuitiv halte ich das für
lösbar, finde mich aber aufgrund mangelnder Ansätze im Netz leicht
irritiert.
MfG
Niels
Re: [PEAR] Transaction Emulation
am 26.02.2005 09:19:31 von Abitos Schrelb
Niels Braczek wrote:
> Moin moin,
>
> sieht jemand eine realistische Chance, den DB-Abstraktionslayern
> DB/DBA/MDB/MDB2 (bzw. einem davon) beizubringen, Transaktionen auf
> MyISAM-Tabellen zu emulieren? Wenn ja: wie? Intuitiv halte ich das für
> lösbar, finde mich aber aufgrund mangelnder Ansätze im Netz leicht
> irritiert.
>
> MfG
> Niels
Hallo Niels,
Das wäre wohl sehr kompliziert. Aber durchaus lösbar.
Du müsstest einen Query ausführen und überprüfen ob er ausgeführt wurde.
Wenn es fehler gab müsstest du alle davor ausgeführten Querys rückgängig
machen. Daneben müsstest du die Datenbank/Tabelle für die dauer der
Transaktion für andere Nutzer sperren.
Man müsste einen Cache bauen, der es erlaubt, die Tabelle jederzeit
zurück zu fahren.
Ich würde den Emulator als Erweiterungsklasse bauen, der nur Funktionen
nutzt die in der Abstraktionsschicht vorhanden sind. Somit wäre der
Emulator auch für andere Datenbanken nutzbar.
mfg Tobias
--
Alle eMails an die genannte Adresse landen in /dev/null
Kontaktinfos auf www.schrelb.de
Re: [PEAR] Transaction Emulation
am 27.02.2005 23:43:33 von Niels Braczek
Abitos Schrelb schrieb:
> Niels Braczek wrote:
>
>> sieht jemand eine realistische Chance, den DB-Abstraktionslayern
>> DB/DBA/MDB/MDB2 (bzw. einem davon) beizubringen, Transaktionen auf
>> MyISAM-Tabellen zu emulieren? Wenn ja: wie? Intuitiv halte ich das für
>> lösbar, finde mich aber aufgrund mangelnder Ansätze im Netz leicht
>> irritiert.
>>
> Das wäre wohl sehr kompliziert. Aber durchaus lösbar.
>
> Du müsstest einen Query ausführen und überprüfen ob er ausgeführt wurde.
> Wenn es fehler gab müsstest du alle davor ausgeführten Querys rückgängig
Das entscheidet ja der Programmierer, indem er ggf. ein Rollback anstößt.
> machen. Daneben müsstest du die Datenbank/Tabelle für die dauer der
> Transaktion für andere Nutzer sperren.
Die Möglichkeit steht ja zur Verfügung. Im MySQL-Manual wird explizit
darauf hingewiesen, dass man das zur Emulation von Transaktionen
verwenden können solle.
> Man müsste einen Cache bauen, der es erlaubt, die Tabelle jederzeit
> zurück zu fahren.
Im Prinzip müsste wohl die ganze Tabelle (bei JOINs alle betroffenen
Tabellen) kopiert, die Transaktion auf der Kopie durchgeführt und
anschließend beim COMMIT die Original-Tabellen mit den Kopien
überschrieben werden. Hört sich teuer an. Zumal man ja bei
START_TRANSACTION noch gar nicht weiß, welche Tabellen betroffen sein
werden und daher alle kopieren müsste. Oder sehe ich da etwas falsch?
> Ich würde den Emulator als Erweiterungsklasse bauen, der nur Funktionen
> nutzt die in der Abstraktionsschicht vorhanden sind. Somit wäre der
> Emulator auch für andere Datenbanken nutzbar.
IMHO macht es am meisten Sinn - wenn überhaupt -, eine solche Emulation
als Erweiterung von MDB2 auszulegen.
MfG
Niels
Re: [PEAR] Transaction Emulation
am 03.03.2005 23:58:36 von Arno Blumenstein
Hallo Niels.
Schau die mal http://www.interakt.ro an die machen sowas auf Basis von
adodb. Leider gibts die Klassen nur als Dreamweaver-Erweiterung, ImpAKT
heist die Erweiterung und ne Demo davon gibt es auch.
Aber deren Lösungsansatz ist schon recht gut.
Gruß Arno
Re: [PEAR] Transaction Emulation
am 04.03.2005 01:15:29 von Niels Braczek
Arno Blumenstein schrieb:
>
> Schau die mal http://www.interakt.ro an die machen sowas auf Basis von
> adodb. Leider gibts die Klassen nur als Dreamweaver-Erweiterung, ImpAKT
> heist die Erweiterung und ne Demo davon gibt es auch.
Danke, ich sehe mir das gleich mal an.
MfG
Niels
Re: [PEAR] Transaction Emulation
am 04.03.2005 02:45:35 von Niels Braczek
Arno Blumenstein schrieb:
> Schau die mal http://www.interakt.ro an die machen sowas auf Basis von
> adodb. Leider gibts die Klassen nur als Dreamweaver-Erweiterung, ImpAKT
> heist die Erweiterung und ne Demo davon gibt es auch.
Soweit ich sehen kann, bietet ImpAKT zwar eine Löschweitergabe, eine
Transaktionsemulation konnte ich in der Beschreibung allerdings nicht
erkennen. Und ich möchte wetten - wenn ImpAKT das könnte, hätten die
Macher das sehr deutlich herausgestellt.
Trotzdem vielen Dank für den Tipp!
MfG
Niels
Re: [PEAR] Transaction Emulation
am 04.03.2005 10:25:03 von Arno Blumenstein
Hallo Niels
> Soweit ich sehen kann, bietet ImpAKT zwar eine Löschweitergabe, eine
> Transaktionsemulation konnte ich in der Beschreibung allerdings nicht
> erkennen. Und ich möchte wetten - wenn ImpAKT das könnte, hätten die
> Macher das sehr deutlich herausgestellt.
> Trotzdem vielen Dank für den Tipp!
Wenn Du mit Transaktionsemulation, das Sperren und Entsperren von
Datensätzen im Bearbeitungsmodus meinst, das kann impAKT nicht.
Aber eine Emulation der Abhängikeit deiner Querys (update, insert,
delete) geht sehr wohl.
So wird das eine Query nicht ausgeführt, wenn das andere nicht
funktioniert/fehlerhaft ist bzw umgedreht.
Wenn Du darüber mehr Infos möchtest, dann werte ich mal versuchen dir
einen gescheiten Codeschnipsel zu senden.
gruß Arno
Re: [PEAR] Transaction Emulation
am 04.03.2005 13:26:41 von Niels Braczek
Arno Blumenstein schrieb:
> Aber eine Emulation der Abhängikeit deiner Querys (update, insert,
> delete) geht sehr wohl.
> So wird das eine Query nicht ausgeführt, wenn das andere nicht
> funktioniert/fehlerhaft ist bzw umgedreht.
Es geht darum, im Fehlerfalle (wobei der Fehler nicht auf DB-Seite sein
muss) Änderungen an der DB rückgängig zu machen. Stichworte BEGIN,
ROLLBACK, COMMIT.
> Wenn Du darüber mehr Infos möchtest, dann werte ich mal versuchen dir
> einen gescheiten Codeschnipsel zu senden.
Ja, gerne. Meine E-Mail-Adresse funktioniert.
MfG
Niels
Re: [PEAR] Transaction Emulation
am 04.03.2005 14:00:31 von Arno Blumenstein
Hallo Niels
Bsp ist unterwegs
Gruß Arno
Re: [PEAR] Transaction Emulation
am 04.03.2005 14:36:59 von Frank-Christian Kruegel
On Sat, 26 Feb 2005 01:25:22 +0100, Niels Braczek
wrote:
>sieht jemand eine realistische Chance, den DB-Abstraktionslayern
>DB/DBA/MDB/MDB2 (bzw. einem davon) beizubringen, Transaktionen auf
>MyISAM-Tabellen zu emulieren? Wenn ja: wie? Intuitiv halte ich das für
>lösbar, finde mich aber aufgrund mangelnder Ansätze im Netz leicht
>irritiert.
Wo ist das Problem, gleich eine Datenbank wie PostgreSQL oder Firebird zu
nehmen, die schon seit jeher Transaktionen beherrscht?
Mit freundlichen Grüßen
Frank-Christian Krügel
Re: [PEAR] Transaction Emulation
am 04.03.2005 15:55:33 von Niels Braczek
Frank-Christian Kruegel schrieb:
> Wo ist das Problem, gleich eine Datenbank wie PostgreSQL oder Firebird zu
> nehmen, die schon seit jeher Transaktionen beherrscht?
Das ist ansich kein Problem. Ich arbeite allerdings an einem Projekt,
das Transaktionen benötig(t|en wird) und auf möglichst vielen
Plattformen laufen soll, insbesondere MySQL - wegen der Verbreitung. Da
es immer noch Provider gibt, die MySQLs InnoDB-Unterstützung abschalten,
würde ich gerne weiterhin MyISAM-Tabellen verwenden *können* (mit klarer
Empfehlung, wenn möglich InnoDB zu verwenden).
MfG
Niels
Re: [PEAR] Transaction Emulation
am 04.03.2005 17:25:48 von Niels Braczek
Arno Blumenstein schrieb:
> Bsp ist unterwegs
Danke, ich hab's mir angesehen. Es bietet tatsächlich in geringem Umfang
Transaktionen, reagiert aber nur auf eigene Fehler. Bei irgendwelchen
Exceptions von außen wird kein automatisches ROLLBACK angestoßen. Daher
ist es leider für meinen Zweck nicht verwendbar.
Allerdings hat es mich auf eine Idee gebracht. Sie ist noch nicht reif
genug, um hier vorgetragen zu werden, was ich aber gerne nachhole, falls
ich zu konkreten Ergebnissen komme.
MfG
Niels
Re: [PEAR] Transaction Emulation
am 04.03.2005 17:58:07 von Arno Blumenstein
Hallo Niels.
> Bei irgendwelchen
> Exceptions von außen wird kein automatisches ROLLBACK angestoßen. Daher
> ist es leider für meinen Zweck nicht verwendbar.
> Allerdings hat es mich auf eine Idee gebracht. Sie ist noch nicht reif
> genug, um hier vorgetragen zu werden, was ich aber gerne nachhole, falls
> ich zu konkreten Ergebnissen komme.
Würde mich auch brennend intressieren, wie man Fehler von aussen
abfangen könnte.
Wir haben hier auch schon mit tmp_tables experimentiert, aber das bringt
auch nicht genügend Sicherheit ums letztendlich einzusetzen, vorallem
weil der Aufwand ziemlich groß ist und leztlich die Performance leidet.
Also, wenn Du eine gescheite Idee hast - lass es mich wissen.
Gruß
Arno