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

Поиск
Список
Период
Сортировка
От Uwe C. Schroeder
Тема Re: Verhindern, dass im Mehrbenutzerbetrieb mit veralteten Daten gearbteitet wird
Дата
Msg-id 200405051100.06834.uwe@oss4u.com
обсуждение исходный текст
Ответ на Verhindern, dass im Mehrbenutzerbetrieb mit veralteten Daten gearbteitet wird  (darkburgundi@onlinehome.de (Bastian))
Список pgsql-general
-----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-----


В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Cache lookup failure for pg_restore?
Следующее
От: "scott.marlowe"
Дата:
Сообщение: Re: Load Balancing and Backup