Id Generation for multiple forms

Question

Can anyone suggest if i use below code to generate id for my files, will it be unique always. As 100s forms create the form at same automatically which auto populate ids in ID textbox. So it should be thread safe and If i restart the application it should not ever repeat the id which already generated before the application stop anytime.

  private static final AtomicLong count = new AtomicLong(0L);  
    public static String generateIdforFile()  
    {
        String timeString = Long.toString(System.currentTimeMillis(), 36);
        String counterString = Long.toString(counter.incrementAndGet() % 1000, 36);
        return timeString + counterString;
    }

And forms are getting the Id using ClassName.generateIdforFile();

IF you have DB; then you can go for sequence so that though your APPLICATION is restarted DB still provide next sequence value. — Kanagavelu Sugumar, Oct 14 '13 at 09:34

score 1 · Answer 1 · edited May 23 '17 at 11:57

Why not just use a UUID for your file id? You could use something like the following:

public static String generateIdforFile()  {
    return UUID.randomUUID().toString();
}

Or do you need a (ongoing) numeric value?

If the number just has to be numeric (and not ongoing) you could use UUID#getLeastSignificantBits() or UUID#getMostSignificantBits() for the numeric value.

Quoting this answer on SO:

So the most significant half of your UUID contains 58 bits of randomness, which means you on average need to generate 2^29 UUIDs to get a collision (compared to 2^61 for the full UUID).

You will of course not be as collision secure as using the full UUID.

score 0 · Answer 2 · answered Oct 14 '13 at 08:18

0

If you are making method as synchronized there is no need to use AtomicLong variables.

Because concurrency is ensured by using synchronized keyword.

Using excessive concurrent variables hampers efficiency and performance of application.

answered Oct 14 '13 at 08:18

Scientist

1,458
2
15
31

Thanks, but can you tell will val variable give unique values always as it is getting drive from System.currentTimeMillis() and uniqueness will not hamper for Ids In any case like i asked Application restart should not regenerate any of the id which already generated before application stops. – Vivek Dhiman Oct 14 '13 at 08:41
Why not add the PID then ? – Laurent LA RIZZA Oct 14 '13 at 09:41
Well a combination of both System.currentTimeMillis() and PID will make it more concrete and supply us with unique values. – Scientist Oct 14 '13 at 09:43
Have a look at this question: http://stackoverflow.com/questions/35842/how-can-a-java-program-get-its-own-process-id – Laurent LA RIZZA Oct 14 '13 at 12:19

score 0 · Answer 3 · answered Oct 14 '13 at 08:38

0

Better use a global AtomicLong starting at 0L for you entire application. Then you concatenate with CurrentTimeMillis.

static AtomicLong counter = new AtomicLong(0L);

public static String generateIdforFile()  
{
    String timeString = Long.toString(System.currentTimeMillis(), 36);
    String counterString = Long.toString(counter.incrementAndGet() % 1000, 36);
    return timeString + counterString;
}

This has greater chances to yield unique IDs, even between application restarts, provided that your app takes a bit more than some milliseconds to shutdown and restart. Note that the method is not synchronized anymore. (no need) And provided also, that you create less than a thousand files in the same millisecond. But you can't guarantee universal uniqueness.

answered Oct 14 '13 at 08:38

Laurent LA RIZZA

2,905
1
23
41

Thanks, Sorry there can be around 1000 of file can trigger at once to get ID,that is why i applied sleep. UUID i dont want to use because of its length. Just want by using this code ID should be unique for future independent upon application/server crash and after recovery should not conflict with older file ids. – Vivek Dhiman Oct 14 '13 at 09:33
Then change the modulus to 10000 or 100000 or any power of 36, by the way. ;) Or drop the modulus altogether. This method should NOT have an explicit sleep. And by the way, I don't know any platform on which Sleep(1) is doing what you expect. Sleep releases the timeslot allocated to your thread, and does not guarantee that you get another time slot exactly 1 ms later. Just AT LEAST 1ms later (more likely 10ms or 20ms). The process I am describing guarantees uniqueness provided that the `counter` variable is not reset within the same millisecond. – Laurent LA RIZZA Oct 14 '13 at 09:39
Hi i have update the code, Can you tell now is it OK. Or in which scenario it can create duplicates. – Vivek Dhiman Oct 14 '13 at 09:56
No, it's not OK. You can't declare a method inside a method. The code I have given you creates duplicates if, within the same millisecond, either 1000 file IDs are requested, or the application is shutdown and restarted in less than 1ms, or if NTP corrects your system clock so that the exact same system time happens many times during the same day. – Laurent LA RIZZA Oct 14 '13 at 12:10

Id Generation for multiple forms

3 Answers3