Пессимистические отношения блокировки с транзакцией базы данных

Question

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

НАЧАЛО СДЕЛКИ

//pessimistic locking

совершение сделки

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

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

Answer 1

На самом деле для таких ситуаций следует использовать оптимистическую блокировку. Может использоваться следующим образом:

1. Пользователь просит пользовательский интерфейс получить запись для редактирования.
2. Сервер выбирает записи и передает их в пользовательский интерфейс. Предположим, в это время запись быть отредактированным имел версию 1. Теперь база данных освобождена. нет Ресурсы базы данных хранятся, поскольку мы не знаем, выдаст ли пользователь запрос на обновление или нет .
3. Теперь пользователь редактирует данные в пользовательском интерфейсе и запрашивает их обновление на сервере с помощью исходный номер версии, отправленный на шаге 2.
4. Теперь из пула соединений с БД взято новое согласие базы данных, и запись обновляется в БД, если оригинальная запись в БД имеет ту же версию, что и была отправлен в пользовательский интерфейс на шаге 2. Это версия записи, представленной на шаге 4 изменено перед отправкой запроса на редактирование, вы должны попросить пользователя снова редактировать со свежими данными.

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

Но если очень важно удерживать ресурсы с блокировками записи до фиксации транзакции, тогда следует использовать Pessimitic

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

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

В этой ситуации имеет смысл удерживать блокировку Pessimitic до завершения транзакции бронирования. Даже в этой ситуации у пользователя нет блокировок и транзакций. полный разговор.

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

Answer 2

Не очень практично создавать такую ​​систему блокировки. Даже если бы вы могли сделать это как-то, это серьезно ограничило бы количество пользователей, которым разрешен доступ к серверу.

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