This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Hi All I want to create Unique Id(s) and as far as requirement is concerned , java program should create every time a unique number. Could some body help me to provide parameters which could be used to create Unique numbers.
If you use UID as Paul suggests, make sure to read the Javadoc of that class. ID's generated with UID are not globally unique - they are only unique over time on the machine you're generating it on. If you have your program running on different machines, the machines may generate the same UID.
The Javadoc of UID suggests how to generate a globally unique ID:
"An independently generated UID instance is unique over time with respect to the host it is generated on as long as the host requires more than one millisecond to reboot and its system clock is never set backward. A globally unique identifier can be constructed by pairing a UID instance with a unique host identifier, such as an IP address."
A better choice would be the class java.util.UUID, which does generate universally unique identifiers. [ April 13, 2007: Message edited by: Jesper Young ]
Originally posted by Paul Sturrock: Will a UID do?
Actually same code has to be used on multiple JVMs . So i believe UID wont work .Because these Unique id(s)will be persisted in same storage. Moreover approx 10,000 id(s) need to be created from each box(JVM).
UID is from SE 6.0.But if you want to use this in lower versions then might consider using Random() [to create randomness you might want to add new Object().hashcode() in the constructor of Random()]and in case your program will be deployed in different JVM's in different machines then you might also want to use GUID , it considers the ethernet card's physical address too for construction.
Issue with GUID is , it creates number with approx 32 digits . I have to take into consideration max Length as 10 and if i try to manipulate the lenght of GUID generated number , i will loose uniqueness
Originally posted by Remko Strating: You could create an uniqueId by using the nano time
What's the size reduction if you write a 32 digit number in base 36?
I used a compound key technique from a Scott Ambler article years ago. To make unique keys across a cluster we go to the database for a DB2 sequence number for part 1. Then we increment an integer from 0 to 999 (or whatever number of digits you like) for part 2. When part2 maxes out, we go back to the database. So we go to the database once for every 1000 keys. The db sequence number is 10 digits and we format the compound as 00000-00000-000 for human consumption. If and when the db approaches max int we can change the format to 000-00000-00000 or use dots or something.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Rahul Bhattacharjee: But if you want to use this in lower versions then might consider using Random()
That is dangerous advice: randomness is *very* different from uniqueness. Very bad things can happen when you confuse the two.
[to create randomness you might want to add new Object().hashcode() in the constructor of Random()]
That's not necessary at all. The no arg constructor already uses the current system time to create a seed. The trick is to only create one Random object and reuse it - don't create several ones in fast succession.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Nov 29, 2005
Yes , I understand that randomness is very different from uniqueness.
I think there is a thin line differentiating between randomness and uniqueness.Could you please help me understand this.
My understanding is that when a unique number generator generates a number and delivers it to the caller , it doesn't remember / cache the number.So when it generates the next unique number then without comparing with the previously generated values how can the program say that its not been generated before.So it gives the same effect as random generator.
But I do not think that there is any harm in specifying a seed to the constructor of Random() , though absolutely not necessary.
Joined: Aug 05, 2005
Originally posted by Rahul Bhattacharjee: My understanding is that when a unique number generator generates a number and delivers it to the caller , it doesn't remember / cache the number.So when it generates the next unique number then without comparing with the previously generated values how can the program say that its not been generated before.
The whole point of a unique number generator is that it has to have some way of knowing with a high degree of certainty that the number it has generated is unique.
How this is done depends on the scope within which the number has to be unique.
So, if the number only has to be unique for the lifetime of a single running program, then caching each number in memory as it is generated would be one way of doing this.
If the number had to be unique for every program running on a computer for the lifetime of the computer (even if it is switched off), then you would need some sort of permanent store on that computer to hold every number ever generated.
If you want a universally unique number (which is what UUID gives you) then you would want some way of generating a number that you know to be unique without checking it against a store of numbers. Some possible ways of doing this are descibed here.
Originally posted by Rahul Bhattacharjee: I think there is a thin line differentiating between randomness and uniqueness.Could you please help me understand this.
There is no such line. They are separate concepts.
If I want to generate unique IDs for a set of things, I can assign numbers 1, 2, 3, and so on. There is no randomness involved at all in this case.
If I toss a coin, I will randomly get heads or tails. Suppose my first toss is a head. If there were any uniqueness involved, then my second toss would be a tail. But in fact there is randomness involved, and my second toss will be randomly a head or a tail.
Are you writing the UIDs to a database (presumably along with other data)? Is it a shared database (i.e. all the VMs write to the same DB)? How tight are the performance constraints? Why 10 chars ? I've worked on a project that generates globally unique IDs on multiple, independent boxes but we use 56 to 64 characters (depending on the representation) and knowing a bit about how it works I don't believe we could use fewer.
Possible solutions: 1.) Use a DB to generate the unique IDs (i.e. a sequence) 2.) Use DB to generate a sequence but have each VM grab some large block in one operation. 3.) Each VM generates its own sequence, prepended with a unique prefix.
There are probably some more esoteric solutions but these are the common things I've seen.
Joined: Nov 29, 2005
Originally posted by Paul Clapham: There is no such line. They are separate concepts.
Thanks Paul for the explanation.
Say , I have a system which sits in middle of an legacy system and clents.Any application/client which needs to communicate with the legacy application has to go through the middle system.Middle systems except xml's and gives xml replies.The xml requests have a ID field which has to be unique.Many enternal systems can request the middle system.So for this senario what would be the best idea for generating an ID and under stressed conditions the middle system may receive many reuqests symultaneously from many external systems.
Would UUID be the right approach for generating ID's for this senario.
Joined: Jan 29, 2003
Joanne's description of scope was very helpful. Your description sounds like a cloud of clients with no common scope, which makes UUID a good fit.
You could have all the clients participate in the compound key scheme I mentioned before, but it can be a nasty Single Point Of Failure. Where I used it, if the database can't vend sequence numbers, we're probably out of business anyhow. I suppose your "service in the middle" could vend sequence numbers with the same understanding - if it's not available for keys it's not available for service either.
Any chance to change the whole design so the middle tier generates the keys while processing the request and returns them? I know in my case it wasn't practical - the clients had to know the key before sending the request.