GoldenLine
Zaloguj się
Tomasz Zadora

Tomasz Zadora programuję

Temat: Strategia unikania deadlocków

Myślę o takiej strategii unikania deadlocków jak: ustalenie priorytetu blokowania (SHARED/EXCLUSIVE) pojedynczych rekordów lub zakresu w tabelach.

Tworzymy kontrolera kolejności blokowania tabel InnoDB: dla każdej tabeli w bazie ustalamy pewien priorytet liczbowy, powiedzmy, że czym wyższa liczba tym wcześniej tabela powinna być blokowana / ma pierszeństwo przed tymi z niższa liczbą (lub odwrotnie - nie ważne).

Po starcie transakcji dla absolutnie każdego zapytania SQL tworzącego lock (shared/exclusive) wysyłamy do kontrolera informacje o tym wraz z nazwą tabeli która będzie zablokowana, jeżeli próbujemy blokować w nieodpowiedniej kolejności kontroler zgłasza błąd.

Takie rozwiązanie teoretycznie wg. dokumentacji MySQL powinno gwarantować, że nigdy nie wystąpi deadlock - co najwyżej może spowodować timeout w oczekiwaniu na uzyskanie locka.

Zgadza się, czy nadal jest jakaś możliwość wystąpienia deadlock-a ?Tomasz Zadora edytował(a) ten post dnia 01.07.11 o godzinie 23:03
Link do wypowiedziLink

konto usunięte

Temat: Strategia unikania deadlocków

I co ma wynikać z tego rzeźbiarstwa, bo nie widzę jakiegoś większego sensu w tym poście... Ja mam w jednym projekcie ( co prawda nie OLTP ) 5k tabel/widoków, jak mi ustalisz tutaj priorytet? Może będziesz data-mining robił i reguły asocjacji odkrywał?

Ja bym zaczął od doczytania jak powinno się modelować dane i wykorzysywać transakcje a nie rzeźbił bez sensu.
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Strategia unikania deadlocków

"I co ma wynikać z tego rzeźbiarstwa, bo nie widzę jakiegoś większego sensu w tym poście... "

To może przeczytaj jeszcze raz ten post, nie rozumiesz prostego założenia ?

Z tego "rzeźbiarstwa" ma wynikać brak deadlocków w transakcjach - o tym jest ten post.

Możesz sobie zaprojektować relacje i zrobić strategie poszczególnych transakcji, ale jeżeli nie będziesz zawsze, w tej samej kolejności lockował tabel to masz możliwość wystąpienia deadlocka - przynajmniej w InnoDB.

Po za tym skoro używasz takich mocnych słów jak "bez sensu" to podaj proszę inną strategię unikania deadlocków, bo trollować każdy umie.
Link do wypowiedziLink

konto usunięte

Temat: Strategia unikania deadlocków

i tu padnie odpowiedź
a co to jest deadlock?
Link do wypowiedziLink

konto usunięte

Temat: Strategia unikania deadlocków

http://en.wikipedia.org/wiki/Deadlock

Tomek, dobry temat, mieliśmy jeden problem z deadlockami, muszę przemyśleć co opisałeś, nie pamiętam jak/czy go rozwiązaliśmy.Tomasz Grzechowski edytował(a) ten post dnia 04.07.11 o godzinie 00:28
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Strategia unikania deadlocków

Dodatkowe obserwacje:

1) Byłby problem gdybyśmy chcieli np. zablokować rekordy/indeksy w tabeli A, później B (dobra kolejność) i znowu A (teraz błąd) - w ramach tej samej transakcji. Może być więcej sytuacji podobnych do 1), gdzie przestrzeganie założenia może być trudne.

2) Trzymanie się tego priorytetu niejako wymuszałoby tworzenie prostych i krótkich transakcji, dodałbym jeszcze: eleganckich.

3) Na razie nie widzę możliwości wystąpienia deadlocka gdyby faktycznie udawało się zawsze przestrzegać priorytetu, więc pod tym względem jest to raczej dobre rozwiązanie (?).
Link do wypowiedziLink

konto usunięte

Temat: Strategia unikania deadlocków

my używaliśmy select for update .. do tworzenia kolejki oczekującej, wiadomo, że lockują się wiersze konkretne, ale i tak mieliśmy problem z deadlockiem

ale tak jak mówię potrzebuję więcej czasu na weryfikację jak obecnie to rozwiązaliśmy :D
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Strategia unikania deadlocków

Jak się dogrzebiesz to daj znać - jestem ciekaw. Na razie robie tak, że wykrywam deadlock (odpowiedni numer erroru) i restartuje transkacje, ale to mi się nie podoba.

Natomiast SELECT FOR UPDATE też może powodować deadlock, jeżeli:

Połączenie 1 zablokuje rekord lub index lub zakres indexu w tabeli A, połączenie 2 zablokuje inny rekord/etc. w tabeli B, następnie połączenie 1 chce zablokować ten sam rekord/index co pol. 2 w tabeli B i czeka na to a w tym samym momencie połączenie 2 chce zablokować ten sam rekord/index co pol. 1 w tabeli A - i mamy deadlock.

Materiał pomocniczy:

http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlock...

Cytat:

"Access your tables and rows in a fixed order. Then transactions form well-defined queues and do not deadlock."

Właśnie po przeczytaniu tego wpadłem na pomysł z tymi priorytetami.Tomasz Zadora edytował(a) ten post dnia 04.07.11 o godzinie 12:49
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Strategia unikania deadlocków

Mała aktualizacja tematu: problem deadlocków dotyczy także row-locków na poziomie pojedynczej tabeli, nie wystarczy lockować tabele w odpowiedniej kolejności, dobrze by było to samo robić z rekordami.

Na przykład:

Połączenie I
SELECT * FROM `product` WHERE id = '12' FOR UPDATE

Połączenie II
SELECT * FROM `product` WHERE id = '84' FOR UPDATE

Połączenie I
SELECT * FROM `product` WHERE id = '84' FOR UPDATE // Czekanie...

Połączenie II
SELECT * FROM `product` WHERE id = '12' FOR UPDATE // DEADLOCKTomasz Zadora edytował(a) ten post dnia 10.07.11 o godzinie 11:30
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Stawiamy czoła wyzwaniom! ...




Wyślij zaproszenie do
Anuluj