Параллельный пользователь получает дескриптор одного и того же документа одновременно
У нас есть редкая производственная проблема в базе данных Notes. Наша система присваивает ID документу запроса во время отправки (сохранение, затем отправка в режиме реального времени). Случается так, что иногда 2 документа имеют одинаковый идентификатор, чего не должно быть.
Идентификатор имеет формат YYYY-MM-XXX, где YYYY - текущий год, MM - номер месяца, XXX - число, начинающееся с 001 и далее. При присвоении идентификатора система проверяет, где находятся документы за те же месяцы. Если он не видит документ, он назначает 001 в идентификаторе, в противном случае он получает последний документ в представлении, получает номер, а затем увеличивает его на 1. Новый номер будет назначен в качестве идентификатора.
Как я могу убедиться, что в ходе этого процесса я могу назначить уникальный идентификатор на основе вышеуказанных критериев? Ошибка настолько редка, что мы не можем ее смоделировать снова. Спасибо за помощь!
3 ответа
Вы можете использовать метод блокировки объекта NotesDocument, чтобы сначала заблокировать документ перед обновлением числа в нем. В случае, если заходит другой пользователь, сценарий должен будет дождаться снятия блокировки. Как только блокировка снята, следующий пользователь может заблокировать ее, чтобы обновить.
Согласно ответу @Ken Pespisa, @Unique, скорее всего, даст вам уникальную ценность, но на самом деле это не гарантировано. Если два пользователя с одинаковыми именами (т. Е. Одинаковые первые инициалы, одинаковые первые две буквы фамилии и одна и та же последняя буква фамилии) одновременно выполняют @Unique на двух разных клиентских компьютерах (согласно системным часам), то все еще может быть столкновение. Вероятность низкая, но не нулевая.
Окончательное обсуждение назначения не последовательных идентификаторов документам Notes можно найти в статье Андре Гирарда здесь. На мой взгляд, лучший способ - отложить присвоение уникального последовательного идентификатора и использовать агента, который запускается на сервере для создания идентификатора. Это дает истинную гарантию уникальности (при условии, что вы правильно ее кодируете). Компромисс в том, что идентификатор не доступен сразу.
Некоторый код был бы полезен, чтобы увидеть, в чем заключается проблема, но похоже, что между двумя пользователями, отправляющими документ, они оба смотрят на представление одновременно.
Во время логики проходит много времени, чтобы просмотреть представление, получить последний документ, увеличить его на единицу, сохранить в документе, сохранить этот документ и затем обновить представление, чтобы в следующий раз проверить представление последний документ имеет большее число. Что вам действительно нужно, так это то, что оборачивает все это так, что это может происходить только синхронно. Это легче сказать, чем сделать.
Я бы предложил использовать формулу @ UNIQUE, которая (я считаю) гарантированно будет уникальной вместо XXX части идентификатора. Если вы использовали часть XXX для сортировки, возможно, вы все равно можете сохранить этот порядковый номер где-то в документе, и в худшем случае у вас будет два документа с одинаковым ключом сортировки, что может подойти для ваших нужд.