Минимизация таблицы тупиков в моем сценарии с оракулом и innodb - PullRequest
0 голосов
/ 04 августа 2010

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

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

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

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

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

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

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

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

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

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

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

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

1 Ответ

2 голосов
/ 04 августа 2010

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

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

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

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

...