Albe Laurenz wrote:
> 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.
..was doch ein SERIALIZATION FAILURE, und deshalb absolut korrekt ist an
der Stelle. Bau auf Seite der Applikation einen retry-loop um die ganze
Veranstaltung und gut (und performant).
Im READ COMMITTED mode waere die Alternative noch, mit SELECT .. FOR
UPDATE zu testen, ob's solch ein Tuple schon gibt. Wenn ja, ein UPDATE
drauf, wenn nein den INSERT. Weniger performant als SERIALIZABLE
(pessimistic locking), aber Du sparst Dir damit evtl. den retry-loop in
der App (zumindest wenn Du auch noch darauf achtest, keine deadlocks zu
provozieren).
Gruesse
Markus Wanner
--
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