Transaktion Problem

Hallo,

ich habe folgendes Problem :

Beispiel:

Client A ist mit einer Anwendung auf die PostGres-DB connectet.

Client B ändert (Alter Table…) per Sql-Tool ein Attribut.

Fazit: Durch Client A ist die DB blockiert und das Statement von Client B wird erst abgesetzt wenn Client A Verbindung beendet.

Jemand ne Idee? (gegen Oracle oder Informix geht das problemlos)
Postgres scheint bei der Standardinstallation andere Parameter zu haben.
Auf welchen musss ich meinen Augenmerk richten?


Danke

Nein.

Jemand ne Idee? (gegen Oracle oder Informix geht das problemlos)

Idee bezüglich?

Postgres scheint bei der Standardinstallation andere Parameter zu haben.
Auf welchen musss ich meinen Augenmerk richten?


Danke

Das ist, wenn überhaupt, keine Frage von Installationsparametern. Höchstens von Sperren.


Andreas

@akretschmer

Nein.

doch…

Idee bezüglich?

Problem gelesen??

Das ist, wenn überhaupt, keine Frage von Installationsparametern. Höchstens von Sperren.

Welche Sperren verräts Du nicht…?

Danke für Deine Antworten, aber wirklich weiterhelfen???

@All

bin für brauchbare Tips weiterhin dankbar.

Ciao Wolfgang

Wenn du einen Eintrag in einer Tabelle änderst, wird dieser Eintrag (nur der) gesperrt. Solange diese Transaktion aktiv ist, kann keine andere Verbindung diesen Eintrag ändern.
Möchtest du die Tabelle komplett ändern, musst du alle Einträge schreiben können. Wenn es hier also einen Eintrag gibt, der gesperrt ist, geht das nicht.

Was mich dabei stört: Die Anwendung ist anscheinend ständig mit der Datenbank verbunden. Das ist nicht schlimm. Aber die geänderten Daten werden anscheinend erst committed, sobald man die Anwendung beendet: dann ist es unschön, wenn die Anwendung zwar eigentlich schon alles geschrieben hat, aber dann die Verbindung zur Datenbank (warum auch immer) wegbricht: dann sind alle Änderungen trotzdem weg.

@ads

was Du schreibst ist richtig!

Allerdings läuft die Softeware mit der wir das Problem haben, gegen eine Oracle, Informix und Sysbase -DB ohne den gleichen Effekt.

PostGres macht an dieser Stelle etwas anderes als der Rest, und ich weiss dummerweise nicht was.

Meine Kenntnisse in Postgres sind minimal, aber ich muss unsere Software sowie Daten aus einer Oracle-DB migirieren.

Die Daten waren Problemlos, aber das Verhalten bei bestimmten Sql-Befehlen…

Es ist deFakto tatsächlich so, das es nur bei Befehlen passiert die direkt Physikaliscg an der Db was ändern ( Feld vergrössern, Table löschen, Feld hinzufügen usw.)
Normale Transaktionen wie 2 Leute bearbeiten zur gleichen Zeit den gleichen Datensatz sind kein Problem.

Werde wohl suchen müssen was Postgre da anders macht als der Rest.


Ciao

Ich bezog mich auf das hier:

Client A ist mit einer Anwendung auf die PostGres-DB connectet.
Client B ändert (Alter Table....) per Sql-Tool ein Attribut.
Fazit: Durch Client A ist die DB blockiert und das Statement von Client B wird erst abgesetzt wenn Client A Verbindung beendet.

Und da bleibe ich mal dabei, daß dem nicht so ist.

Problem gelesen??
Ciao Wolfgang

Welches?

Wenn eine Anwendung der Meinung ist, eine Tabelle zu sperren, dann ist das Sache der Anwendung, nicht von PG.

Ich kann das, was von Dir oben als Problem geschildert ist (Client A ist connected und blokiert deswegen Client B) nicht nachvollziehen. Zumindest nicht, ohne von Client A eine Sperre direkt anzufordern. Und ohne es jetzt testen zu wollen und zu können bin ich mir sicher, daß ORA oder beliebige andere Systeme es auch nicht zulassen, ein ALTER TABLE auf eine durch eine andere Anwendung gesperrte Tabelle sofort auszuführen.

Andreas

Du könntest mal schauen, welchen Commitmodus die Anwendung A nutzt. Wenn du explizit BEGIN und COMMIT in der Anwendung nutzt, dürfte sich das Problem erledigen.

In PostgreSQL werden auch DDL Änderungen (also Änderungen an Tabellen ect) innerhalb einer Transaktion abgewickelt. In Mysql findet das keine Beachtung, die Tabelle wird einfach geändert, ist doch egal, was der gerade laufenden Transaktion passiert. In Oracle findet vor DDL-Änderungen ein expliziter Commit statt, das dürfte der Grund sein, warum du da keine Probleme (ok, keine größeren, ein ungefragter Commit ist trotzdem böse) hast. Für Informix kann ich keine Aussagen treffen.

Und da bleibe ich mal dabei, daß dem nicht so ist.

mag ja sein, aber es ist Fakt!


Genau das ist es was ich auch nicht verstehe.


Der Start der Software zeigt in PGAdmin : in Transaction an;
Der Start des SQl-Tools :

Ich kann das, was von Dir oben als Problem geschildert ist (Client A ist connected und blokiert deswegen Client B) nicht nachvollziehen. Zumindest nicht, ohne von Client A eine Sperre direkt anzufordern. Und ohne es jetzt testen zu wollen und zu können bin ich mir sicher, daß ORA oder beliebige andere Systeme es auch nicht zulassen, ein ALTER TABLE auf eine durch eine andere Anwendung gesperrte Tabelle sofort auszuführen.

was anders ist , ist der Treiber zur DB; Die Software (Java) läuft seit 11 Jahren gegen die genannten DBs in der gleichen Version.

Jetzt wollen 2 Neukunden als DB Postgres einsetzen und ich stosse auf dieses problem.



Jeder befehl im Sql-Tool der Änderungen (Physikaliche…) an der DB vornimmt bleibt hängen!

Select, Update, Insert usw gehen Problemlos!

Bekomme leider den Screenshot hier nicht rein.

Das gleiche unter anderen DB geht problemlos!

ads sagte vorhin etwas sehr richtiges und wichtiges: in PG sind auch DDL-Befehle ganz automatisch in einer TX.
Und ein ALTER TABLE erfordert dazu einen exklusiven Look der Tabelle.


Der Start der Software zeigt in PGAdmin : in Transaction an;
Der Start des SQl-Tools :

Deine Software startet eine Transaktion zum Start und macht z.B. ein select auf diese Tabelle.

Jeder befehl im Sql-Tool der Änderungen (Physikaliche…) an der DB vornimmt bleibt hängen!

Durch den Start einer TX in der Anwendung und einem Select auf der Tabelle kannst Du nun keinen exklusiven Look mehr erhalten. Diesen brauchst Du aber für ein ALTER TABLE.

Goldene Regel einer Anwendung sollte sein, Transaktionen nur solange offen zu halten, wie nötig. Deine Anwendung scheint das leider anders zu sehen.


Select, Update, Insert usw gehen Problemlos!

Diese brauchen keinen exklusiven Look.

Bekomme leider den Screenshot hier nicht rein.

Macht nix.

Das gleiche unter anderen DB geht problemlos!

Gehen ja, aber nicht problemlos. Das Problem dabei ist, daß sich die Anwendung in der Transaktion darauf verläßt, daß sich die Stuktur der Tabelle nicht verändert. Im Gegensatz zu z.B. ORA garantiert PG das. Eher ein Feature, weniger ein Problem.

Andreas

Goldene Regel einer Anwendung sollte sein, Transaktionen nur solange offen zu halten, wie nötig. Deine Anwendung scheint das leider anders zu sehen.

völlige Zustimmung!

…allerdings unterscheiden wir uns bei der Definition: TRANSACTION.

Denn wir definieren eine Transaction als “Ändern von Daten” und nicht als “Lesen von Daten”, da unsere Anwendung zum Verwalten von Daten geschrieben wurde.

Es ist nicht nur so bei Oracle, sondern auch bei Sybase und Informix das ein “Select” nicht als Blockierende AKtion gehändelt wird.

Ich ahhte gehofft in Postgres einen Parameter zu finden mit dem man das ändern könnte, denn eine Software dieses Ausmasses ändern ist zu aufwändig.

Ciao Wolfgang

Du könntest in deiner Anwendung mal testweise autocommit ausschalten. Autocommit bedeutet, das jeder Befehl in PostgreSQL in eine Transaktion gekapselt wird. Sobald ein Befehl abgeschlossen ist, wird eine neue Transaktion gestartet … die dann herumsitzt und wartet, bis der nächste Befehl ankommt.
Ausschalten tut man das in der Anwendung bei den Verbindungseinstellungen.

Übrigens ist deine “Definition” einer Transaktion auch nicht richtig.
Es ist falsch, das ein SELECT keine Daten ändert. Im Gegenteil, durch den Select können Funktionen aufgerufen werden, die intern trotzdem Daten verändern.
Aus diesem Grund wird jede Operation in einer Transaktion abgearbeitet, die du entweder in deiner Anwendung explizit startest oder die implizit von PostgreSQL gestartet wird (autocommit). Wird die Leseoperation erfolgreich beendet: schön. Gab es beim Lesen einen Fehler, können alle ev. aufgetretenen Änderungen zurückgerollt werden.

Du hast Recht, das ein SELECT nicht blockierend ist, im Normalfall jedenfalls. Dein Problem ist, das die zweite Operation, die DDL-Änderung, einen sehr exklusiven Lock auf die Tabelle benötigt. Dieser Lock sperrt auch einen SELECT aus.

Und was ich mich die ganze Zeit frage: was ist das für eine Tabellenänderung, die ihr da durchführt und warum stellt die ein Problem dar? Sprich, wie häufig führt ihr diese Änderung durch?

Einschalten, ads. EINSCHALTEN.

Andreas

Wieso einschalten?
Wenn ich den Standard richtig lese, ist das erzwingen einer Transaktion sowieso vorgeschrieben (nebenbei: wieder ein Punkt, gegen den Mysql verstößt?). Mit aktiviertem Autocommit (Default) wird nach jedem SQL Befehl ein COMMIT durchgeführt. Mit deaktiviertem Autocommit muss man das selbst erledigen.

Weil die Anwendung ‘idle in transaction’ ist. Sicheres Zeichen für “\set AUTOCOMMIT off” (steht in meiner ~/.psqlrc). Und ja: wenn es deaktiviert ist, muß man selbst das COMMIT schicken. Tut die Anwendung nicht.
Deswegen: mal einschalten, falls es geht. Dann dürfte ein select from foo anschließend ein alter foo einer anderen Anwendung nicht blockieren, weil ja ein AUTOCOMMIT kam. Okay?

Andreas

moin,

Dann dürfte ein select from foo anschließend ein alter foo einer anderen Anwendung nicht blockieren, weil ja ein AUTOCOMMIT kam. Okay?

Zu Deinem Beispiel:

nach einem Select auf die FOO ist es irrelevant auf welche Tabelle ich ein ALTER absetzte!!! …es sind alle Blockiert!


Autocommit: Nicht möglich das es etliche Befehle in der Anwendung gibt bei denen ein Autocommit das gewünschte unterbinden würde.

… Frust…

Und was ich mich die ganze Zeit frage: was ist das für eine Tabellenänderung, die ihr da durchführt und warum stellt die ein Problem dar? Sprich, wie häufig führt ihr diese Änderung durch?

Es handelt sich um eine Standarsoftware (= Normal-User) und einen Part für Admins. In dem Adminpart kann man ausschliesslich über die Software Tabellen ändern, Attribute hinzufügen, Löschen, ändern usw.
Also die gesamte Anwendung so konfigurieren wie man es möchte und ist nicht abhängig von Programmierung.

Ciao