> > Aufgrund einer Abneigung gegen Exceptions schreibe ich so
> > etwas meist in der Form:
> >
> >| UPDATE Table SET Something = 'something' WHERE ID = 'id';
> >| IF NOT FOUND THEN
> >| INSERT INTO Table (ID, Something) VALUES ('id', 'something');
> >| END IF;
>
> ...was aber bei Nebenläufigkeit ohne explizites Locking zu Race Conditions
> führt. Was ist das Problem an Exceptions?
Sie fressen (laut Doku) Performance, denn intern werden sie mit Savepoints
implementiert.
Es stimmt allerdings, daß zwei solche Statements wie oben einander in die
Quere kommen können.
Allerdings lassen sich auch mit der "INSERT zuerst"-Methode Race Conditions
mit anderen Statements nicht ohne weiteres vermeiden:
CREATE TABLE test (id integer PRIMARY KEY, val text);
INSERT INTO test (id, val) VALUES (1, 'Wert');
Session A: Session B:
START TRANSACTION;
SAVEPOINT a;
INSERT INTO test (id, val) VALUES (1, 'Session a');
(ERROR: duplicate key value violates unique constraint "test_pkey")
DELETE FROM test WHERE id = 1;
ROLLBACK TO a;
UPDATE test SET val = 'Session a' WHERE id = 1;
(UPDATE 0)
COMMIT;
Wenn man die Transaktion in Session A serealisierbar macht
(START TRANSACTION ISOLATION LEVEL SERIALIZABLE in Session A),
wird der Erfolg auch nicht glücklich machen, dann bekommt die
Session A einen Error 40001.
Liebe Grüße,
Laurenz Albe
--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein
No comments:
Post a Comment