Hi, I need to generate a UNIQUE and RANDOM number say for a transaction number and password generation. If I use the Random class like Random ranObj = new Random(); int tranNumber = ranObj.nextInt(); Does this would always give a UNIQUE number? Coz I need to store this in the database table in a primary key column in identify the transaction. Is there�s a better way which would guarantee the uniqueness across the application lifetime? Thanks, - VJ
Vijay, There is no way to guarantee that you will not get a duplicate. Random means that you can get any number. I have done a lot of tests for a recent Algorithms class. That said you could increase your range of numbers, but to be on the safe side you should do a lookup in the DB and see if the number already exists and then if it does fetch another random number. When I say to seed it I mean like this: randomInt(i, max); Where i is some small number and max is a large number. I hope this helps. SAM
We make a living by what we get, we make a life by what we give!
Vijay, Random numbers won't work for a unique identifier. Try this based on the system clock. It's still not guaranteed to give unique numbers if you reset the system time.
Another method would be to keep the next available number in a file and increment it each time it is used. Finally, if you are using a database, can you just use an autonumber field in the table to create this automatically? [ November 26, 2003: Message edited by: Tom Blough ]
Tom Blough<br /> <blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Cum catapultae proscriptae erunt tum soli proscripti catapultas habebunt.<hr></blockquote>
Random is tough, but sequential is easy. My current system uses a common scheme. The database has a "next available number" for each component. The component that inserts new records asks the key vendor "give me 1000 numbers". The key vendor might read the database and get the number 1, add 1000 and put 1001 back in the database, then return 1-1000 to the component. Now the component can do 1000 guaranteed unique inserts by just incrementing an in-memory counter before it has to go back to the key vendor. If the system crashes or shuts down for the night, some numbers might go unused but there is no risk of duplicates. In the early 90s when I first used DB/2 the DBAs told us not to use sequential keys because physical disk storage routines got clogged up when you always add to the end of an index. So we used a timestamp with the digits reversed as the leading part of the key to slightly randomize the inserts. Our Oracle group says sequential is no longer a concern, but ya never know. Finally, google on Java GUID generators and see how strongly they guarantee uniqueness.
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