Question

I have requirement in which I continuously receive messages that needs to be written in a file. Every time a new message is received it needs to be written in a separate file. What I want is to generate an unique identifier to be used as a file-name. I also want to preserve the order of the messages as well. By this I mean, the identifier generated as a file-name should always be incremental.

I was using UUID.randomUUID() to generate file-names but the problem with this approach is that UUID only assures randomness of the identifier but is not incremental. As a result I am losing the ordering of the file (I want file generated first should appear first in the list).

Approaches known

1. Can use System.currentTimeMillis() but I can receive multiple messages at same time stamp.

2.Another approach could be to implement static long value and increment it whenever a file is to be created and use the long value as a file-name. But I am not sure about this approach. Also it doesn’t seem to be a proper solution to my problem. I think there could be far better solutions than this one.

If someone could suggest me a better solution to this problem, will be highly appreciated.

Answer 1

If you want your id value to uniformly rise even between server restarts, then you must either base it on the system time or have some elaborately robust logic that persists the last ID used. Note that achieving robustness on its own is not hard, but achieving it in a performant and scalable way is.

If you additionally need the id to be unique across multiple nodes in a redundant server cluster, then you need even more elaborate logic, which definitely involves a persistent store to which all the boxes synchronize access. Making this performant is, of course, even harder.

The best option I can see is to have a quite long ID so there’s room for these parts:

1. System.currentTimeMillis for long-term uniqueness (across restarts);
2. System.nanotime for finer granularity;
3. a unique id of each server node (determined in a platform-specific way).

The method will still have to remember the last value generated and retry in case of a duplicate. It won’t have to retry too many times, though, just until the next nanoTime clock tick—it could even busy-wait for it.

Sketch of code without point 3 (single-node implementation):

private static long lastNanos;
public static synchronized String uniqueId() {
  for (;/*ever*/;) {
    final long n = System.nanoTime();
    if (n == lastNanos) continue;
    lastNanos = n;
    return "" + System.currentTimeMillis() + n;
  }
}