2010-06-24 2 views
1

Есть ли способ гарантировать, что приложение не преминет освободить блокировки строк в Oracle? Если я обязательно поставлю фиксаторы в блоках finally, которые обрабатывают случай непредвиденных ошибок, но что, если процесс приложения просто внезапно умрет до того, как он совершит (или кто-то ударит кабель питания/кабель lan).Оказывает ли Oracle автоматическое откат заброшенных сеансов?

Есть ли способ заставить Oracle автоматически откатывать сеансы бездействия после X-го времени? Или откат, когда я каким-то образом обнаружил, что соединение было потеряно?

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

Спасибо.

ответ

2

Попробуйте установить SQLNET.EXPIRE_TIME в свой sqlnet.ora.

SQLNET.EXPIRE_TIME=10 

Из documentation:

Назначение
Чтобы задать временной интервал, в течение нескольких минут, чтобы послать чек, чтобы проверить, что соединения клиент/сервер являются активными.

+0

Это звучит как ответ. Существуют ли какие-либо серьезные недостатки в использовании этой функции? Почему Oracle не делает это по умолчанию? Документы перечисляют несколько недостатков, но я не вижу, как любой из них оправдывает отключение этой функции по умолчанию. – jthg

+0

Что делать, если ваши запросы занимают 2 часа? :) – bwawok

+0

Согласно связанной документации, он просто проверяет, жив ли клиент после EXPIRE_TIME. Если клиент отвечает каждый раз, запрос может занять столько времени, сколько потребуется. – jthg

0

Я не DBA, поэтому я уверен, что вы можете найти лучшее решение ...

но есть определенные условия, которые кажутся тупиковыми случиться, что не будет отката самостоятельно. У моего последнего DBA был процесс, который запускался каждую минуту и ​​убивал все, что было запущено более 10 минут.

+0

Это очень плохая идея. Если ваша база данных становится очень большой, вы можете очень легко убить работу с статистикой сбора, например (или, что еще хуже, сделать резервную копию). – Allan

+0

Ну, вы должны быть осторожны, что вы позволите ему убить, это был материал, запущенный сервером приложений (который собирает статистику или резервное копирование не будет). – bwawok

1

COMMIT inside, наконец, вероятно, последнее, что вам нужно сделать, поскольку вы должны (почти) никогда не совершать ничего, что порождало исключение.

+0

К сожалению, вы правы. – jthg

Смежные вопросы