Cúram-generated Unique IDs address a perennial problem in application design - how to co-ordinate multiple processes each of which needs to allocate a number guaranteed to be unique throughout the application. One classic approach involved locking and updating a key control database table each time a key needs to be allocated. Unfortunately, this can lock the control table for the duration of long-lived transactions, preventing other processes from accessing it. This technique is almost always the source of serious database contention problems in an application (see "Allocating Sequence Numbers" from Chapter 12 of High Performance Client/Server, Loosley and Douglas).
Unique IDs are served out in blocks of 256 keys using a unique ID generator, also know as the Key Server1. A process requests a block of Unique IDs by calling the key server. This updates a database control table each time it returns a block of Unique IDs to a requesting process. Once a block has been allocated, the requesting process can allocate keys from this block locally, i.e. without calling the server again, until the Unique ID block is exhausted. Furthermore, the key server operates in its own transaction so it never locks the key control table for longer than it takes to allocate and update a next Unique ID block value.
It should be noted, however, that a process which requests a Unique ID block may or may not use the keys from that block. If it does not, then the unused keys represent holes in the key sequence. Processes which use, say, one key value before shutting down will leave quite large holes in the key sequence. Note also that there is no time limit on how long a process can wait between allocating a Unique ID block, and using the key values in it. Thus, even for human-readable keys which are in an ascending sequence starting at 1, the sort order of keys on the database has no direct bearing on the chronological order in which they were inserted. Obviously, programs should not assume that this is the case.