Unique Number Server  Unique Number Server

This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project.

This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project, and research the information yourself to solve them.

Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.

Though I am a programmer, 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 in any way you please and to keep all the profits from your endeavour.

Please do not email me about this project without reading the disclaimer above.

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 (Media Access Control) address. Unfortunately you need JNI (Java Native Interface) 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 UUID (Universally Unique Identifier) specification. UUIDs are 128-bit integers.


CMP homejump to top You can get the freshest 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
logo
Please email your , letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : feedback email. If you want your message, your name or email kept confidential, not considered for public posting, please explicitly specify that. Unless you state otherwise, I will treat your message as a letter to the editor that I may or may not publish in the feedback section. After that, it will be too late to retract it. If you disagree with something I said, please quote it and cite the web page where you found it, tell me why you think it is wrong, and, if possible, provide some supporting evidence. Threatening to kill me or spouting obscenities has yet to persuade me to change my mind.
mindprod.com IP:[65.110.21.43]
view BlogYour face IP:[38.107.179.214]
You are visitor number 8,810.