deadlock w triggerze

Przed insertem/updatem do tabeli X sprawdzam dosyc skomplikowany warunek dotyczacy unikalnosci danych wykorzystujac do tego celu trigger. Niestety bez odpowiedniej ochrony nie jest to odporne na race condition. W pierwszej linijce triggera dodalem w tym celu LOCK (exclusive) na tabeli X. W ten sposob mam odpowiedni poziom ochrony jednak jesli wykonam dwa inserty w 'tym samym momencie' dostaje deadlock. PostgreSQL najwyrazniej blokuje tabele shared lockiem zanim wykona sie trigger. Rozumiem to w ten sposob:

1. proces dla pierwszego inserta probuje uzyskac exclusive locka i zasypia, bo drugi insert zdazyl juz zablokowac tabele shared lockiem,
2. proces dla drugiego inserta probuje uzyskac exclusive locka i PostgreSQL wykrywa deadlocka,
3. drugi proces wypuszcza blokade i konczy sie z rollbackiem,
4. pierwszy proces kontynuuje i konczy commitem.

Pytanie: jak rozwiazac ten problem bez deadlocka? Nie chodzi mi o rozwiazanie w aplikacji tylko po stronie bazy. Po stronie aplikacji moglbym np. probowac wykonac operacje kilka razy ale za bardzo komplikuje to sprawy. Przydalaby sie mozliwosc wplyniecia na locka, ktorego PostgreSQL bierze automatycznie przy insercie. Gdyby dalo sie np. zwiekszyc jego poziom na exclusive wtedy nie potrzebowalbym brac drugiego locka w triggerze.

Ostatnio edytowany przez ptr (2009-04-03 15:02:32)