Thread: Verhindern, dass im Mehrbenutzerbetrieb mit veralteten Daten gearbteitet wird

Hi,

ich benutze PHP und PostgreSQL.
Folgendes Problem: Eine Seite zeigt die Daten, die in einer Tabelle
der DB abgespeichert sind. Der Benutzer wählt dann einen Datensatz
aus, den er gerne bearbeiten oder löschen möchte. Auf der nächsten
Seite wird die Aktion dann ausgeführt.
Es ist möglich LOCKS zu setzen, um zu verhindern, dass sich 2 DELETES
bzw. UPDATES in die Quere kommen, bzw. werden implizit gesetzt. Aber
wenn ein Benutzer sich auf Seite 1 also auf der Tabellenabfrageseite
befindet, und ein anderer Benutzer während dessen die Daten in der
Tabelle verändert, so arbeitet Benutzer 1 mit den alten Daten und
löscht dann z.B. einen Datensatz der zwar die gewünschte Nr hat, aber
nicht mehr der Datensatz ist, den er eigentlich löschen wollte.
Ist es vielleicht möglich per Abfrage zu prüfen, ob gerade ein LOCK
gesetzt ist?

Bastian

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Bastian,

die liste pgsql-general@postgresql.org is 99% in englisch. Deine Anfrage hat
wesentlich mehr Aussicht auf Erfolg wenn die sie in englisch stellst.

Zum Problem: kannst du die Datensätze nicht eindeutig identifizieren ? Um
erfolgreich einen Lock zu setzen muss die Tabelle einen primary key haben,
der dann eindeutig ist. Damit hättest du zumindest nicht das Problem daß ein
Datensatz gelöscht wird der "zwar die gewünschte Nr hat, aber nicht mehr der
Datensatz ist". Du kannst explizite rowlocks setzen, aber wie gesagt es ist
einfacher die rows eindeutig zu identifizieren, dann kann der Benutzer mit
der veralteten Ansicht zwar noch löschen, der delete geht dann aber ins
leere. Nur ein update auf den veralteten datensatz wird einen fehler
erzeugen, den deine Applikation dann mit entsprechender fehlermeldung
abfangen muss.

UC

On Tuesday 04 May 2004 01:50 am, Bastian wrote:
> Hi,
>
> ich benutze PHP und PostgreSQL.
> Folgendes Problem: Eine Seite zeigt die Daten, die in einer Tabelle
> der DB abgespeichert sind. Der Benutzer wählt dann einen Datensatz
> aus, den er gerne bearbeiten oder löschen möchte. Auf der nächsten
> Seite wird die Aktion dann ausgeführt.
> Es ist möglich LOCKS zu setzen, um zu verhindern, dass sich 2 DELETES
> bzw. UPDATES in die Quere kommen, bzw. werden implizit gesetzt. Aber
> wenn ein Benutzer sich auf Seite 1 also auf der Tabellenabfrageseite
> befindet, und ein anderer Benutzer während dessen die Daten in der
> Tabelle verändert, so arbeitet Benutzer 1 mit den alten Daten und
> löscht dann z.B. einen Datensatz der zwar die gewünschte Nr hat, aber
> nicht mehr der Datensatz ist, den er eigentlich löschen wollte.
> Ist es vielleicht möglich per Abfrage zu prüfen, ob gerade ein LOCK
> gesetzt ist?
>
> Bastian
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

- --
    UC

- --
Open Source Solutions 4U, LLC    2570 Fleetwood Drive
Phone:  +1 650 872 2425        San Bruno, CA 94066
Cell:   +1 650 302 2405        United States
Fax:    +1 650 872 2417
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAmSumjqGXBvRToM4RAoJTAJ42xi25CzUpgnbjUrEJutTCF9+OxQCbBzSh
BxpIwG8QEsIPxQUp39U5Fa8=
=7BB1
-----END PGP SIGNATURE-----

Hallo Uwe,

zunächst einmal danke für die schnelle Antwort und den Tipp meine
Anfrage auf Englisch zu stellen. Ich werde das beim nächsten Mal
berücksichtigen.

Zum Problem: Wenn ich die Datensätze eindeutig identifiziere, kann ich
das Problem nicht beheben.
Beispiel:
Ausgangstabelle:

Nr      daten
1       testdaten1
2       testdaten2
3       testdaten3

Wenn nun Benutzer 1 den Datensatz mit der Nr.2 - also "testdaten2" -
löscht, so sollen sich die Nummern verschieben und die Tabelle sieht
folgendermaßen aus.

Nr      daten
1       testdaten1
2       testdaten3

Der zweite Benutzer würde dann also bei einem Zugriff auf Nr.2 nicht
wie gewünscht "testdaten2" löschen, sondern "testdaten3".
Wenn sich die Nummern nicht verschieben würden, also die Tabelle so
aussieht:

Nr      daten
1       testdaten1
3       testdaten3
dann würde der DELETE bzgl. Nr.2 ins Leere gehen.


Bastian


uwe@oss4u.com ("Uwe C. Schroeder") wrote in message news:<200405051100.06834.uwe@oss4u.com>...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Bastian,
>
> die liste pgsql-general@postgresql.org is 99% in englisch. Deine Anfrage ha
> t
> wesentlich mehr Aussicht auf Erfolg wenn die sie in englisch stellst.
>
> Zum Problem: kannst du die Datens tze nicht eindeutig identifizieren ? Um
>
> erfolgreich einen Lock zu setzen muss die Tabelle einen primary key haben,
>
> der dann eindeutig ist. Damit h ttest du zumindest nicht das Problem da
>   ein
> Datensatz gel scht wird der "zwar die gew nschte Nr hat, aber nicht meh
> r der
> Datensatz ist". Du kannst explizite rowlocks setzen, aber wie gesagt es ist
>
> einfacher die rows eindeutig zu identifizieren, dann kann der Benutzer mit
>
> der veralteten Ansicht zwar noch l schen, der delete geht dann aber ins
>
> leere. Nur ein update auf den veralteten datensatz wird einen fehler
> erzeugen, den deine Applikation dann mit entsprechender fehlermeldung
> abfangen muss.
>
> UC
>
> On Tuesday 04 May 2004 01:50 am, Bastian wrote:
> > Hi,
> >
> > ich benutze PHP und PostgreSQL.
> > Folgendes Problem: Eine Seite zeigt die Daten, die in einer Tabelle
> > der DB abgespeichert sind. Der Benutzer w hlt dann einen Datensatz
> > aus, den er gerne bearbeiten oder l schen m chte. Auf der n chsten
> > Seite wird die Aktion dann ausgef hrt.
> > Es ist m glich LOCKS zu setzen, um zu verhindern, dass sich 2 DELETES
> > bzw. UPDATES in die Quere kommen, bzw. werden implizit gesetzt. Aber
> > wenn ein Benutzer sich auf Seite 1 also auf der Tabellenabfrageseite
> > befindet, und ein anderer Benutzer w hrend dessen die Daten in der
> > Tabelle ver ndert, so arbeitet Benutzer 1 mit den alten Daten und
> > l scht dann z.B. einen Datensatz der zwar die gew nschte Nr hat, aber
> > nicht mehr der Datensatz ist, den er eigentlich l schen wollte.
> > Ist es vielleicht m glich per Abfrage zu pr fen, ob gerade ein LOCK
> > gesetzt ist?
> >
> > Bastian
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
> - --
>     UC
>
> - --
> Open Source Solutions 4U, LLC    2570 Fleetwood Drive
> Phone:  +1 650 872 2425        San Bruno, CA 94066
> Cell:   +1 650 302 2405        United States
> Fax:    +1 650 872 2417
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQFAmSumjqGXBvRToM4RAoJTAJ42xi25CzUpgnbjUrEJutTCF9+OxQCbBzSh
> BxpIwG8QEsIPxQUp39U5Fa8=
> =7BB1
> -----END PGP SIGNATURE-----
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Bastian,

warum die Tabelle nicht so aufbauen:

create table jadajada (
    internal_number serial primary key,
    nr int4,
    testdaten varchar(254)
);

die "internal_number" wird dann automatisch von postgres vergeben. Dann kannst
du deine nummern umschieben wie du willst, die interne nummer wird sich nie
ändern. Die interne nummer benutzt du um den delete, update etc. zu
kontrollieren ala:

delete from jadajada where internal_number=12345;

Die Nr. degradiert zu einem normalen datum was beliebig geändert werden kann.
Du gibst die interne nummer in deiner Applikation natürlich nicht aus. Die
wäre für den Benutzer eher verwirrend.

Uwe


On Thursday 06 May 2004 02:40 am, Bastian wrote:
> Hallo Uwe,
>
> zunächst einmal danke für die schnelle Antwort und den Tipp meine
> Anfrage auf Englisch zu stellen. Ich werde das beim nächsten Mal
> berücksichtigen.
>
> Zum Problem: Wenn ich die Datensätze eindeutig identifiziere, kann ich
> das Problem nicht beheben.
> Beispiel:
> Ausgangstabelle:
>
> Nr      daten
> 1       testdaten1
> 2       testdaten2
> 3       testdaten3
>
> Wenn nun Benutzer 1 den Datensatz mit der Nr.2 - also "testdaten2" -
> löscht, so sollen sich die Nummern verschieben und die Tabelle sieht
> folgendermaßen aus.
>
> Nr      daten
> 1       testdaten1
> 2       testdaten3
>
> Der zweite Benutzer würde dann also bei einem Zugriff auf Nr.2 nicht
> wie gewünscht "testdaten2" löschen, sondern "testdaten3".
> Wenn sich die Nummern nicht verschieben würden, also die Tabelle so
> aussieht:
>
> Nr      daten
> 1       testdaten1
> 3       testdaten3
> dann würde der DELETE bzgl. Nr.2 ins Leere gehen.
>
>
> Bastian
>
>
> uwe@oss4u.com ("Uwe C. Schroeder") wrote in message
> news:<200405051100.06834.uwe@oss4u.com>...
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > Bastian,
> >
> > die liste pgsql-general@postgresql.org is 99% in englisch. Deine Anfrage
> > ha t
> > wesentlich mehr Aussicht auf Erfolg wenn die sie in englisch stellst.
> >
> > Zum Problem: kannst du die Datens tze nicht eindeutig identifizieren ? Um
> >
> > erfolgreich einen Lock zu setzen muss die Tabelle einen primary key
> > haben,
> >
> > der dann eindeutig ist. Damit h ttest du zumindest nicht das Problem da
> >   ein
> > Datensatz gel scht wird der "zwar die gew nschte Nr hat, aber nicht meh
> > r der
> > Datensatz ist". Du kannst explizite rowlocks setzen, aber wie gesagt es
> > ist
> >
> > einfacher die rows eindeutig zu identifizieren, dann kann der Benutzer
> > mit
> >
> > der veralteten Ansicht zwar noch l schen, der delete geht dann aber ins
> >
> > leere. Nur ein update auf den veralteten datensatz wird einen fehler
> > erzeugen, den deine Applikation dann mit entsprechender fehlermeldung
> > abfangen muss.
> >
> > UC
> >
> > On Tuesday 04 May 2004 01:50 am, Bastian wrote:
> > > Hi,
> > >
> > > ich benutze PHP und PostgreSQL.
> > > Folgendes Problem: Eine Seite zeigt die Daten, die in einer Tabelle
> > > der DB abgespeichert sind. Der Benutzer w hlt dann einen Datensatz
> > > aus, den er gerne bearbeiten oder l schen m chte. Auf der n chsten
> > > Seite wird die Aktion dann ausgef hrt.
> > > Es ist m glich LOCKS zu setzen, um zu verhindern, dass sich 2 DELETES
> > > bzw. UPDATES in die Quere kommen, bzw. werden implizit gesetzt. Aber
> > > wenn ein Benutzer sich auf Seite 1 also auf der Tabellenabfrageseite
> > > befindet, und ein anderer Benutzer w hrend dessen die Daten in der
> > > Tabelle ver ndert, so arbeitet Benutzer 1 mit den alten Daten und
> > > l scht dann z.B. einen Datensatz der zwar die gew nschte Nr hat, aber
> > > nicht mehr der Datensatz ist, den er eigentlich l schen wollte.
> > > Ist es vielleicht m glich per Abfrage zu pr fen, ob gerade ein LOCK
> > > gesetzt ist?
> > >
> > > Bastian
> > >
> > > ---------------------------(end of
> > > broadcast)--------------------------- TIP 1: subscribe and unsubscribe
> > > commands go to majordomo@postgresql.org
> >
> > - --
> >     UC
> >
> > - --
> > Open Source Solutions 4U, LLC    2570 Fleetwood Drive
> > Phone:  +1 650 872 2425        San Bruno, CA 94066
> > Cell:   +1 650 302 2405        United States
> > Fax:    +1 650 872 2417
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.3 (GNU/Linux)
> >
> > iD8DBQFAmSumjqGXBvRToM4RAoJTAJ42xi25CzUpgnbjUrEJutTCF9+OxQCbBzSh
> > BxpIwG8QEsIPxQUp39U5Fa8=
> > =7BB1
> > -----END PGP SIGNATURE-----
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> >                http://www.postgresql.org/docs/faqs/FAQ.html
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

- --
    UC

- --
Open Source Solutions 4U, LLC    2570 Fleetwood Drive
Phone:  +1 650 872 2425        San Bruno, CA 94066
Cell:   +1 650 302 2405        United States
Fax:    +1 650 872 2417
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAmtkBjqGXBvRToM4RAsiTAKC2AwKxVjhhu10pRKREE96bg8jpNQCdFqMR
9DI4/PiQFH01Aq7JVGQHZAM=
=E3qO
-----END PGP SIGNATURE-----

Bastian

you are misunderstanding the difference between the "row
number" (there is no such thing inherent in relational
databases) and the primary key (or any other explicitely
numbering column).

The "row number" would be moving when deleting some records --
if it existed. It doesn't exist, however, and can only be
generated on the fly sequentially numbering the rows appearing
as query results. Thusly the order of rows is arbitrary and
not related to the "row number".

OTOH, the primary key, of course, doesn't change when you
delete a row. Neither does a "counting" column. Any column can
be *made* to change upon deletion by using triggers but at least
for primary keys that would be a very unclean thing to do
usually.

I think you need to think more carefully about your
application design and not select records for deletion based
on their line number in some frontend view but rather based
on their primary key that is kept with the data making up the
frontend display (it needn't be shown, though).

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Hallo Uwe,

danke für deine ausführliche Erklärung. Das ist die Lösung für mein Problem.

MfG

Bastian


uwe@oss4u.com ("Uwe C. Schroeder") wrote in message news:<200405061732.01386.uwe@oss4u.com>...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Bastian,
>
> warum die Tabelle nicht so aufbauen:
>
> create table jadajada (
>     internal number serial primary key,
>     nr int4,
>     testdaten varchar(254)
> );
>
> die "internal number" wird dann automatisch von postgres vergeben. Dann kan
> nst
> du deine nummern umschieben wie du willst, die interne nummer wird sich nie
>
>  ndern. Die interne nummer benutzt du um den delete, update etc. zu
> kontrollieren ala:
>
> delete from jadajada where internal number=12345;
>
> Die Nr. degradiert zu einem normalen datum was beliebig ge ndert werden k
> ann.
> Du gibst die interne nummer in deiner Applikation nat rlich nicht aus. Di
> e
> w re f r den Benutzer eher verwirrend.
>
> Uwe
>