Unique Number Server  Unique Number Server

go to home page Student Projects full screen, hide local find menu Google search web for more information on this topic jump to foot of page translate this page with Babelfish by Roedy Green ©1996-2008 Canadian Mind Products
This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. It does not describe an actual complete program. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; I have too many other projects of my own.

I do contract work for a living, which could include writing a program such as this. However, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project any way you please.

In database applications you often need unique numbers for identifying things, e.g. account numbers, package ids, ticket numbers… If you don’t require absolute uniqueness, here are two techniques: You could use one of the above two techniques, then have a central registry that detects the rare collisions and cleans up after the fact.

The obvious answer is to have a centralised RAM-resident counter that you increment every time somebody needs a new unique number. There are three problems with that simplistic approach.

  1. The centralised counter becomes a bottleneck. Everyone must line up behind it to get a number.
  2. If the central counter goes down, the entire network is paralysed.
  3. If the counter computer crashes, when it wakes up, it does not remember precisely which numbers it has already served. If it is not careful, it may serve duplicates.
You might try to solve that with a redundant computer system, storing the counter in a database record, with transaction processing. This adds huge amounts of I/O overhead, slowing things to a crawl, and still does not let you precisely determine which numbers have already been served.

Ok then, how do you handle it? A number server consists of three threads.

  1. The foreground thread just increments the counter and dispenses unique numbers (or ranges of them).
  2. The second thread works in the background. It marks ranges of numbers on disk as having been dispensed, before it releases them to the foreground thread.
  3. The third background thread, notices when the server is getting low on numbers to serve and asks the mother server for a new large range of numbers to replenish its supply. It uses the same protocol that clients of the satellite number server do.
You need only concern yourself with dispensing unique longs. It is trivially easy to turn these into account numbers with check digits or alphanumeric ids.

Another approach is to use the system clock as your basic unique number generator. You must be very sure it is accurate. If you crash and pick up where you left off, there is no danger of reissuing old numbers.

Most computers now have one or more Ethernet cards. Every ethernet card on the planet is manufactured with a unique 48-bit MAC address. Unfortunately you need JNI to get at it from Java. This gives you a way of stamping generated serial numbers with the source that generated them.

There is now a IETF UUID Universally Unique IDentifier specification. Safehaus has implemented it. UUIDs are 128 bit integers.


CMP homejump to top
CMP logo
feedback Please email your feedback for publication, errors, omissions, broken/redirected link reports
and suggestions to improve this page to Roedy Green : feedback email
made with CSS
HTML Checked!
ICRA ratings logo
mindprod.com IP:[65.110.21.43]
Your face IP:[38.103.63.61] Take the DavidSuzuki.org nature challenge
You are visitor number 4,477.
You can get a fresh copy of this page from: or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
http://mindprod.com/project/uniquenumber.html J:\mindprod\project\uniquenumber.html