karlsonchik
Суть такова: как избежать DeadLocks.


1. Установить единый порядок изменения записей БД для всех транзакций.
2. Работать с БД короткими системными транзакциями (тем более что речь идёт про Web).
3. Обработать взаимоблокировку и автоматически повторить транзакцию.
4. Странно, что взаимоблокировки стали проблемой. Я сними редко сталкиваюсь и то только в серверных приложениях, которые автоматически изменяют миллионы записей в сутки.

karlsonchik mcureenab karlsonchik
Суть такова: как избежать DeadLocks.


3. Обработать взаимоблокировку и автоматически повторить транзакцию.

тогда всречный вопрос )))) Каким образом можно обработать взаимо блокировку в Java????

Если SQL запрос не может быть выполнен из-за взаимоблокировки, СУБД поднимает исключение в этом запросе.
На стороне JVM драйвер доступа к БД это исключение может обернуть в исключение Java и тогда нужно его ловить в блоке обработки исключений, или просто вернуть код ошибки (для Java это экзотика), тогда нужно проверять этот код оператором if.
Отменяешь транзакцию, увеличиваешь счётчик попыток и переходишь к началу процедуры.
Или, если количество попыток исчерпано, поднимаешь исключение.

karlsonchikДелать ли один connection к БД на каждый отдельный пользовательский сеанс, и передавать его в сессии. Или в одном сеансе, в каждом классе, работающем с БД стоит делать свой екземпляр connection?

Не ясно, что ты понимаешь под "классом, работающем с БД". Если под каждый SQL запрос использовать отдельное подклчюние к БД, проблем будет очень много. И неразрешимые на уровне СУБД взаимоблокировки, и несогласованность данных.


1. Пусть у создан объект "сеанс пользователя", который живёт от момента регистрации пользователя в Web приложении, до выхода и хранит его состояние.

Тогда "connection к БД" можно использовать несколькими способами.

а. Создать в каждом сеансе пользователя свой "connection к БД". Этот подход позволит не завершать транзакцию БД между http запросами, но когда пользователей очень много, для хранения всех "connection к БД" потребуется много памяти как на в сервере приложений, так и в СУБД.
Чаще используется другой подход.
б. Создаёся пул "connection к БД" оптимального размера. В процессе выполнения http запроса "сеанс пользователя" находит в пуле свободный "connection к БД" и забирает его для выполнения всех своих запросов к БД (если в пуле нет свободных подключений, создаётся дополнительный "connection к БД"). Перед завершением обработки http запроса, "сеанс пользователя" завершает свою транзакцию БД и возвращает "connection к БД" в пул.

Если пользователь работает с Web приложением не создавая сеанса, то нужно использовать модифицированный подход б.

В процессе выполнения http запроса объект "http запрос" находит в пуле свободный "connection к БД" и забирает его для выполнения всех своих запросов к БД. Перед завершением обработки http запроса, "http запрос" завершает свою транзакцию БД и возвращает "connection к БД" в пул.

Как правило работа с пулом подключений к БД скрыта от разработчика приложения. Требуется только соблюдать некоторые стандарты (например, всегда завершать транзакцию), и настроить сервер приложений.

karlsonchikУважаемые господа.... Тут вот ещё один вопрос назрел )))))) как в Java отследить закрыта ли транзакция или нет. Вот, например, у меня есть хранимая процедура, которая заполняет временную таблицу. эта процедура повешена на кнопку... Пользователь нажимает на неё и ждёт пару сек... но если он не дождался и нажал кнопку ещё раз, то база виснет: очень вырастают ред-логи, рбс, КОРОЧЕ завал ))))) Так вот каким образом я могу в java проверить следующие моменты: отработала ли процедура или нет, произошёл ли комит(завершена ли транзакция)

Я конечно решил эту траблу примитивно пока)))))) по онклик делаю кнопку desable.... но это не есть хороший выход

Проще всего использовать синхронный вызов к БД. Пока хранимая процедура не завершится, нужно полностью блокировать форму для ввода. В любом случае в одном подключении к БД в каждый момент времени может выполняться не более одного запроса.

Фиксировать транзакцию должно твоё приложение, иначе ты не сможешь обеспечить когерентность локального буфера записей с таблицами БД. Таким образом ты можешь отследить наличие активной транзакции в твоём приложении.

karlsonchik mcureenab
На стороне JVM драйвер доступа к БД это исключение может обернуть в исключение Java и тогда нужно его ловить в блоке обработки исключений.

Уважаемый, mcureenab!!! А можно про это по подробнее, если не затруднит... ))))))
И вообще большущее спасибо что откликнулись )))))))) !!!!!!

Почитай про классы доступа к БД, про их методы выполнения SQL запросов и про исключения, которые они поднимают.
Про обработку исключений Java написано в каждом букваре.

AlexTheRavenЯ когда-то учил сервер понимать, ушёл ли пользователь с сайта, применяя на клиенте JavaScript, но это ненадёжно. В результате если пользователь резко ушёл с сайта - запрос может остаться незакоммиченным, объекты БД - заблокированными, соединение - висящим в пустоте и кушающим ресурсы.

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

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