Свернуть тупик таблицы в моем сценарии с помощью oracle и innodb

Question

У меня есть 35 функций, которые обновляют от 1 до 3 таблиц в транзакции. Однако они не просто выполняют обновления, но также выполняют запросы.

• В таблице 1 перечислены только действия по обновлению и некоторые запросы.
• В таблице 2 представлены запросы и обновления уровня строки к существующим строкам, а иногда удаляются и добавляются строки. В таблице 2 могут быть запросы в транзакции до и после удаления строк и/или вставки, а также обновления.
• В таблице 3 перечислены обновления, основанные на результатах вышеуказанных действий в таблице 2.

Мое первое действие будет состоять в том, чтобы убедиться, что все 3 обновления выполнены в конце.

Таблица 1 не зависит от других 2 таблиц и, вероятно, может быть первой или последней. Итак, таблица 2 должна прийти перед изменением таблицы 3.

Моя первая забота заключается в том, что с действиями в таблице 2 я выполняю запросы, затем обновляет, затем запрашивает больше запросов, а затем больше обновлений. Должен ли я перезапустить свой код, чтобы это не сделать.

Вторая проблема заключается в том, что таблица 3 представляет собой таблицу, в которой потоки сервлетов должны быть быстрыми. Таблица 3 используется для простых запросов сама по себе. Но похоже, что блокировки на уровне строк остановят эти запросы.

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

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

В принципе, я ищу указатели о том, что следует учитывать. Конечно, я мог бы принудительно блокировать полную таблицу на таблице 2, а затем таблицу 3 в начале каждой функции обновления, но тогда мой поток запросов сервлета Table3 пострадает. Так что это не похоже на решение.

Кроме того, меня беспокоит только относительно самой таблицы 2, что некоторые функции выполняют запросы, обновления на основе запроса, новые запросы на основе обновления, а затем больше обновлений, включая текущие результаты, до обновлений таблицы 3. Это кажется действительно противным.

Рекомендации? Andy

Могут быть одновременные обновления для тех же строк из 2 таблиц, и я позаботился о том, чтобы ударить по ним обновлениями в том же порядке. Одна из таблиц имеет 2 индекса и кажется, что для обновления индекса требуется блокировка таблицы? Некоторые из функций запрашивают таблицу 1, обновляют таблицу 1, затем опционально запрашивают таблицу 2, а затем обновляют таблицу 2 в цикле повтора. В этой таблице содержатся все дочерние отношения родителя в дереве всего моего содержимого, поэтому это обновление большого объема для всех пользователей.

Answer 1

Во-первых, запросы в Oracle (и я считаю, InnoDB) не используют блокировку, если вы не используете FOR UPDATE.

Во-вторых, я не знаю ни одной шкалы приложений. Сколько параллельных транзакций вы ожидаете? Ожидаете ли вы, что они будут обновлять одни и те же строки?

Тип приложения, которое может страдать от взаимоблокировок, - это система бронирования или продажи билетов (например, люди, пытающиеся забронировать те же места в театре), особенно в ситуациях с высоким уровнем параллелизма (новое шоу становится доступным для бронирования).

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