2012-01-23 12 views
6

Jesteśmy coraz wyjątki takie jak tenC3P0 - pozorny impasu na MSSQL, ale nie PostgreSQL lub MySQL

com[email protected]5b7a7896 -- APPARENT DEADLOCK!!! Complete Status: 
Managed Threads: 3 
Active Threads: 3 
Active Tasks: 
    co[email protected]55bc5e2a (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1) 
    co[email protected]41ca435f (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2) 
    co[email protected]460d33b7 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0) 
Pending Tasks: 

podczas testowania naszej aplikacji na MSSQL 2008 R2 obciążenia (jTDS lub urzędowy MS JDBC nie ma znaczenia) . Nigdy nie otrzymujemy tego wyjątku podczas uruchamiania tych samych testów przeciwko PostgreSQL lub MySQL.

Nie chcemy tylko zwiększać liczbę wątków pomocniczych dla c3p0 (która rozwiązuje problem, ale jak długo?). Chcemy wiedzieć, jaki jest problem, ponieważ chodzi o działania z innymi DBMS ".

Aplikacje zachowuje się jak:

  • Send X żąda
  • odczekaj chwilę -> impasu
  • Send X żąda
  • odczekaj chwilę -> impasu

Czy ktoś wie lub ma pomysł, dlaczego mamy takie zachowanie z MSSQL?

Dzięki Adrian

(Btw. BoneCP działa bez problemu zbyt.)

+0

Co to za narzędzie i dlaczego zgłasza "pozorny impas" zamiast rzeczywistego impasu? SQL Server wykrywa rzeczywiste zakleszczenia. Możesz śledzić wykres zakleszczenia, aby następnie zdiagnozować przyczyny jego wystąpienia. –

+0

Witaj Martin, sam SQL Server nie dostaje zakleszczeń. Wygląda na to, że właśnie c3p0 (połączenie puli lib dla Javy) zakłada istnienie zakleszczenia. – Adrian

+0

Adrian - czy możesz wyjaśnić, czy użycie BoneCP pozwoliło uniknąć problemu? – tgdavies

Odpowiedz

3

SQL Server ma znacznie bardziej restrykcyjne strategię blokowania porównaniu do PostgreSQL lub InnoDB.

Szczególnie blokuje WYBIERZ wiersze (tabele?), Które są aktualizowane z innego połączenia/transakcji (w domyślnej instalacji).

Należy upewnić się, że nie wybiera się tych samych wierszy w jednej sesji, które są aktualizowane od innej.

Jeśli nie możesz zmienić sekwencji kodu, możesz uciec z używaniem "brudnych odczytów" w SQL Server.

Jeśli dobrze pamiętam, że właściwie, to jest realizowane poprzez dodanie WITH NOLOCK do SELECT (ale nie jestem do końca pewien)

Edit
Inna możliwość (jeśli jesteś na SQL Server 2005 lub później) byłoby użyć nowej "izolacji snapshot", aby uniknąć blokowania wyborów.

+0

Program SQL Server ma również izolację migawki. –

+1

@MartinSmith: Wiem. Właśnie dlatego powiedziałem "domyślna instalacja". Ale masz rację: przejście do izolacji migawki może również rozwiązać ten problem. –

+0

Nie powiedziałeś "domyślna instalacja". Może to myślałeś! –

Powiązane problemy