1

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!

John Bautista
  • 1,480
  • 3
  • 29
  • 60
  • Have the duplicate ID documents been submitted exactly at the same time? Is the database on one server only and not used as a local replica? – Panu Haaramo Dec 21 '13 at 18:48

3 Answers3

1

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.

user3374530
  • 11
  • 1
0

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.

Ken Pespisa
  • 21,989
  • 3
  • 55
  • 63
  • I've seen quite a number of ids calculated using unique to be the same. Possibly it was linked to my use in Evaluate: Evaluate("@Unique"), but I had to renounce it and use self coded algo – Normunds Kalnberzins Dec 23 '13 at 07:53
  • I haven't seen that personally but that crossed my mind while writing this answer. I couldn't find anything that said it was guaranteed to be unique either, which means it is probably not guaranteed. Perhaps rolling your own is safest :) – Ken Pespisa Dec 23 '13 at 12:13
0

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.

Richard Schwartz
  • 14,463
  • 2
  • 23
  • 41