Concurrent user gets handle to same document at the same time

Question

We have a rare production issue on a Notes database. Our system assigns an ID to a request doc during submission (saving then submit, in real time). What happens is that sometimes 2 documents appear to have the same ID, which should not be the case.

The ID is in the format YYYY-MM-XXX, where YYYY is current year, MM is month in number, XXX is a number starting from 001 then beyond. The system, when assigning id, checks in a view where documents for the same months are there. If it does not see a document, it assigns 001 in the ID, else, it gets the latest document in the view, gets the number, then increment it by 1. The new number will be then assigned as ID.

How can I assure that during this process, I can assign a unique id based on the criteria above? The bug is so rare that we cannot simulate it again. Thank you for your help!

Answer 1

Some code would be helpful to see where the problem lies, but it sounds like there is a race condition between two users submitting a document where they both look at the view at the same time.

There is a lot of time passing during the logic for looking at the view, getting the latest doc, incrementing it by one, storing that on the document, saving that document, and then updating the view so that the next time the view is checked the latest doc has a higher number. What you really need is something that wraps that all so it can only happen synchronously. That's easier said than done.

I'd suggest using the @UNIQUE formula, which is (I believe) guaranteed to be unique in place of the XXX part of the ID. If you were using the XXX part for sorting, perhaps you can still save that sequential number somewhere in the document and at worst case you'll have two documents with the same sorting key, which may be fine for your needs.

Answer 2

As per @Ken Pespisa's answer, @Unique is much more likely to give you a unique value, but it's not really guaranteed. If two users with similar names (i.e., same first initial, same first two letters of last name, and same last letter of last name) execute @Unique on two different client computers at exactly the same time (as per system clocks), then there can still be a collision. The probability is low, but not zero.

The definitive discussion of assigning unqiue sequential ids to Notes documents can be found in Andre Guirard's article here. In my opinion, the best technique is to defer assigning the unique sequential id, and allong an agent that runs on a server to create the id. That provides a true guarantee of uniqeuness (as long as you code it properly). The tradeoff is that the id is not immediately available.

Answer 3

You could use the lock method of NotesDocument object to first lock the document before updating the number in it. In case another user comes in, the script would need to wait till the lock is released. Once the lock is released the next user can lock it down to update it.