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.)
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. –
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
Adrian - czy możesz wyjaśnić, czy użycie BoneCP pozwoliło uniknąć problemu? – tgdavies