Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: Transaktion Problem

  1. #1
    Vierm ist offline Neuer Benutzer
    Registriert seit
    22.05.2007
    Beiträge
    11

    Standard 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

  2. #2
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von Vierm Beitrag anzeigen
    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.
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  3. #3
    Vierm ist offline Neuer Benutzer
    Registriert seit
    22.05.2007
    Beiträge
    11

    Standard

    @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

  4. #4
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    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.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  5. #5
    Vierm ist offline Neuer Benutzer
    Registriert seit
    22.05.2007
    Beiträge
    11

    Standard

    @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

  6. #6
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von Vierm Beitrag anzeigen
    @akretschmer



    doch...
    Ich bezog mich auf das hier:

    Code:
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  7. #7
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    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.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  8. #8
    Vierm ist offline Neuer Benutzer
    Registriert seit
    22.05.2007
    Beiträge
    11

    Standard

    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 : <IDLE> in Transaction an;
    Der Start des SQl-Tools :<IDLE>

    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!
    Geändert von Vierm (14.11.2007 um 15:08 Uhr)

  9. #9
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von Vierm Beitrag anzeigen
    mag ja sein, aber es ist Fakt!


    Genau das ist es was ich auch nicht verstehe.
    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 : <IDLE> in Transaction an;
    Der Start des SQl-Tools :<IDLE>
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  10. #10
    Vierm ist offline Neuer Benutzer
    Registriert seit
    22.05.2007
    Beiträge
    11

    Standard

    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

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Fehler Transaktion in Middleware?
    Von klimaschreck im Forum Programmierung
    Antworten: 10
    Letzter Beitrag: 17.08.2009, 09:57
  2. Transaktion bedingt abbrechen
    Von schoetbi im Forum SQL
    Antworten: 4
    Letzter Beitrag: 03.02.2009, 11:14
  3. Frage Transaktion über zwei Datenbanken
    Von billy-rat im Forum Allgemeines
    Antworten: 4
    Letzter Beitrag: 01.09.2008, 08:55
  4. Select Nextval in Transaktion
    Von byte im Forum SQL
    Antworten: 3
    Letzter Beitrag: 10.04.2007, 07:40
  5. Rollback bei Fehler in Transaktion
    Von mwbond im Forum Programmierung
    Antworten: 10
    Letzter Beitrag: 04.01.2006, 16:30

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum