Каково поведение пессимистической блокировки при доступе к принадлежности или другим отношениям? - PullRequest
1 голос
/ 24 мая 2019

Я использую пессимистическую блокировку в своем коде сброса пароля.

В основном происходит то, что пользователь предоставляет токен (который был отправлен им по электронной почте в предыдущей транзакции), затем в сервисе состояние восстанавливается с помощью PasswordResetRequest.findByToken(token, [lock: true]). Происходит некоторая проверка (был ли токен действителен? Истек ли срок действия запроса?), И затем пользователь, связанный с этим запросом сброса, получает значение request.user (отношение PasswordResetRequest belongsTo User). Затем пароль пользователя обновляется, пользователь сохраняется, а PasswordResetRequest удаляется.

Я знаю, что согласно документам, PasswordResetRequest будет заблокирован (и, таким образом, новый запрос будет заблокирован при его получении). Но как насчет User, который с этим связан? Что произойдет, если у меня будет другой запрос, который читает пользователя по идентификатору, обновляет и сохраняет его (скажем, пользователь чудесным образом обновлял свою учетную запись в то же время, когда он сбрасывал свой пароль)?

Так что мой вопрос: при блокировке дочернего элемента, который belongsTo родитель, блокируется ли родитель? Если нет, то как бы мне этого добиться (нужно ли мне выполнять извлечение информации или что-то в этом роде)?

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

1 Ответ

0 голосов
/ 03 июня 2019

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

Что касается вашего вопроса, все записи, которые будут извлечены, когда вы уже активировали блокировку, также будут заблокированы. Поэтому, если вы выполните request.user, экземпляр пользователя также будет заблокирован (по идентификатору).

Также, если вы не уверены, что все работает хорошо, я бы рекомендовал сделать небольшой тест. Вставьте sleep (2000) (сделайте задержку) в свой метод сброса пароля (после «инициализации» пользователя), а затем вызовите другой метод, который попытается обновить ввод пользователя, в случае сбоя.

...