What if I require contiguous human-readable Unique IDs?

Human-readable IDs allocated by the key server are sequential, but can have gaps for two reasons:

• the IDs are allocated in blocks of 256 keys. When the server is restarted, the remaining values in any block for any key set that has been loaded are discarded.
• if a transaction that requests a human readable ID from the key server is rolled back, the ID that was served up is discarded (as the key server runs in a separate transaction, its transaction commits irrespective of what happens to the application transaction - this is important for performance reasons).

In instances where there is a requirement to generate human-readable IDs, where the numbers must be both sequential and have no gaps, Cúram uses an application defined "key" table for each set of IDs (for example, InternalPersonID, InternalEmployerID, etc). An example of such a business requirement is the one around the issuing of "Social Security Numbers". These tables are read and updated in the context of the application transaction, meaning, the ID is only allocated if the record bearing that ID is committed to the database. Otherwise, the whole business transaction, including the ID allocation, is rolled back. It is worth noting that there is a performance overhead because of this, as the single row ID table is a database hot spot that must be updated every time the record bearing that ID is committed to the database.

Thus it is recommended that:

• this method of ID generation is used only when absolutely necessary and
• your design should strive to ensure that transactions using this mechanism are kept as short as possible to minimize contention on the key table.