Превышено время ожидания запроса на блокировку SQL-сервера .. снова

У меня возникла проблема с попыткой увеличить время ожидания блокировки в SQL Server SP. Независимо от того, что я пытаюсь, он продолжает выдавать «Превышено время ожидания запроса блокировки». Я использую java + jtds 1.2.2, c3p0 0.9.1 и sql server 2008. Настройки, которые я пробовал:

SET LOCK_TIMEOUT 10000 inside the SP and with con.createStatement().execute("SET LOCK_TIMEOUT 10000 ") перед вызовом SP. и в операторе SP: statement.setQueryTimeout(10);

SP вызывается: statement = con.prepareCall("dbo.store_procedure ?,?,?", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY); и устанавливает "SET TRANSACTION ISOLATION LEVEL REPEATABLE READ" внутри

любые предложения? у кого похожие проблемы? заранее спасибо


java sql-server jdbc c3p0 jtds
person francisco    schedule 24.06.2011    source источник
comment
Вы используете REPEATABLE READ и у вас проблемы с блокировкой? Эти двое, вероятно, связаны. Почему вы используете REPEATABLE READ?   -  person JNK    schedule 24.06.2011
comment
у нас есть кластерное приложение, обращающееся к экземпляру сервера sql, и использование REPEATABLE READ (или даже SERIALIZABLE) было единственным способом гарантировать доступ заказа к критической таблице. мы также используем select * из CriticalTable с (ROWLOCK, UPDLOCK, NOWAIT) и INSERT INTO CriticalTable с (ROWLOCK, NOWAIT). спасибо за ответ   -  person francisco    schedule 24.06.2011

Ответы (3)


arrow_upward
1
arrow_downward

Если вы не используете SQL Server 2008 и более поздние версии и указав LOCK_ESCALATION=Disabled, вы можете забыть о подсказке ROWLOCK. SQL Server может и, по моему собственному опыту, вероятно, проигнорирует это и возьмет любую блокировку (страницу или таблицу), которую он заполняет. До SQL Server 2008 не было принудительных подсказок блокировки.

Очистив это, вы можете использовать SET LOCK_TIMEOUT -1, чтобы указать бесконечный тайм-аут.

Я настоятельно не рекомендую вам делать это и вместо этого пытаться устранять неполадки и оптимизировать (при условии, что вы несете ответственность за это) запросы, которые действительно нуждаются в блокировке этой таблицы, максимально ускорить их, чтобы сократить время блокировки.

Отслеживайте заблокированные ресурсы с помощью EXEC sp_lock TargetSPID, чтобы проверить, какие блокировки на самом деле используются.

Еще одно замечание: SET LOCK_TIMEOUT устанавливает время ожидания для текущего соединения, если вы используете пул соединений, вы устанавливаете время ожидания блокировки для всего, что повторно использует это соединение, что может вызвать непреднамеренное поведение в вашем приложении.

person Thiago Dantas    schedule 03.08.2011

arrow_upward
1
arrow_downward

Проверьте, выполняется ли какая-либо транзакция или нет. Одной из причин этой проблемы является наличие незафиксированных транзакций или транзакций без отката.

ВЫБЕРИТЕ @@TRANCOUNT

Используйте приведенную выше команду, чтобы проверить любую существующую транзакцию; зафиксировать или откатить то же самое.

person Teju MB    schedule 17.09.2014

arrow_upward
0
arrow_downward

Проверьте, выполняется ли какая-либо транзакция или нет. Одной из причин этой проблемы является наличие незафиксированных транзакций или транзакций без отката.

ВЫБЕРИТЕ @@TRANCOUNT

Используйте приведенную выше команду, чтобы проверить любую существующую транзакцию; зафиксировать или откатить то же самое.

person zfz    schedule 15.07.2015