Jak uniknąć warunków wyścigu podczas korzystania z metody find_or_create w DBIx :: Class :: ResultSet?

Question

Z dokumentacji dla find_or_create:

Uwaga: Ponieważ find_or_create() odczytuje z bazy danych, a następnie ewentualnie wkładki w oparciu o wynik, metoda ta jest przedmiotem wyścigu stanie. Inny proces mógł utworzyć rekord w tabeli po znalezieniu zakończonym i przed rozpoczęciem tworzenia. Aby uniknąć tego problemu, użyj find_or_create() wewnątrz transakcji.

Czy wystarczy użyć find_or_create() wewnątrz transakcji w PostgreSQL?

Answer 1

Nie, dokumentacja jest niepoprawna. Skorzystanie z samej transakcji nie pozwala na uniknięcie tego problemu. Gwarantuje to tylko, że cała transakcja zostanie wycofana, jeśli wystąpi wyjątek - aby w bazie danych nie było niespójnego stanu.

Do unikaj tego problemu, musisz zablokować tabelę - wewnątrz transakcji, ponieważ wszystkie blokady są zwalniane na końcu transakcji. Coś takiego:

BEGIN; 
LOCK TABLE mytbl IN SHARE MODE; 

-- do your find_or_create here 

COMMIT; 

Ale to nie jest magiczne lekarstwo na wszystko. Może to być problem z wydajnością i mogą występować zakleszczenia (równoczesne transakcje wzajemnie próbujące zablokować zasoby, które zostały już zablokowane). PostgreSQL wykryje taki warunek i anuluje wszystkie oprócz jednej z konkurencyjnych transakcji. Musisz być przygotowany na ponowienie operacji w przypadku niepowodzenia.

The PostgreSQL manual about locks.

Jeśli nie masz dużo współbieżności Państwo może też po prostu zignorować problem. Przedział czasowy jest bardzo mały, więc bardzo rzadko się zdarza. Jeśli zauważysz zduplikowany błąd naruszenia klucza, który nie zaszkodzi, to również to omówiłeś.

Answer 2

Ta implementacja find_or_create powinny zapobiec sytuacji wyścigu, opisaną w PO:

eval { 
    $row = $self->model->create({ ... }); 
} 
if($@ && $@ =~ /duplicate/i) { 
    $row = $self->model->find({ ... }); 
} 

Zmniejsza to także find_or_create() do jednego zapytania w najlepszym wypadku.