A pure timestamp approach doesn't quite work because you can get two keys in a single clock tick. Even if you find a class with nanosecond resolution, it's not really updated more often than the system clock, which just isn't fast enough.
A sequential approach is solid so long as you have a place to reliably save the last key used. Databases are the most reliable or at least report their errors well, but a text file might do for you. Databases have mechanisms to vend sequential numbers so you might just use that.
The overhead of updating a file or database for every key can be high, especially if you have multiple instances of your system across town or the world. A "High/Low" technique helps here. Get the "high" part of the key from the common source, sequence the "low" part of the key from 0 to some max in memory. You only get a new "high" part at startup and when the "low" part overflows.
Do any of those choices sound good?
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
Thai Son Cung
Joined: Aug 25, 2005
Stan James I think I will implement your idea, high/low would be a good choice.
Acttualy if the type of the sessionID is long then we can use Calendar..getTimeInMillis(), but since I have to implement a shared interface and the sessionID there is int,