in reply to Generate a unique ID

If you have a RDBMS nearby, delegate the problem to the database. Create a sequence and fetch a value from it for each running instance. Sure, it looks like overkill, but all major RDBMS have solved all of those nasty litte problems (like parallel access from several systems, atomic updates of the sequence value, running on multiple CPUs in parallel, locking ...).

Actually, I wonder why you would need that unique ID outside a database.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^2: Generate a unique ID
by BrowserUk (Patriarch) on Nov 15, 2010 at 16:13 UTC

    The application requires temporary spill files that need to have unique names that prevent one copy of the program picking up the wrong files. Whether they've been left lying around from a previous aborted run, or because two copies are running concurrently.

    Installing a DB just for this purpose is not a viable option.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      The application requires temporary spill files that need to have unique names

      Is there a reason why you can't use File::Temp?

[reply]

      that prevent one copy of the program picking up the wrong files

      I solved this once using "semaphore files", if a copy of a program picks up a file it checks if the semaphore is there. If it is, it skips the file, if not it creates one. After processing the file it is removed/moved to another directory and the semaphore file deleted. You need some bookkeeping to make it safe.

      It's not clear to me why you need the "uniqueness" at all? If you don't want the slightest chance of a collision I think only the "lastId + 1" remains. You need some sort of locking mechanism of course to control access to the value, e.g. prevent a dirty read. Both timestamps and UUID-like things are not 100% safe. On the other hand, reading through UUID, I would say the chance is probably too small to bother.

      Cheers

      Harry

[reply]
        It's not clear to me why you need the "uniqueness" at all?

        The requirement came out of a real situation.

        A bug caused the program to crash and leave behind some of its temporary files. I was away from the machine at the time. When I came back, I re-ran the program having made a few changes--including correcting the problem that caused the crash I hadn't noticed happen--and the second phase of the code mixed up the content of the previous run with those of the current run. I spent a long time trying to work out why the final output was completely screwed up before noticing that the previous run had terminated badly whilst reviewing the debug trace in the console buffer.

        Imagine how annoying it would be if your system sort utility mixed up spill files from an interrupted run with those generated by the current run.

        Any mechanism that relies upon correct clean-up of either the files themselves or semaphore files is vulnerable to the same issue.

        For the PID + timestamp to fail, the system would have to issue exactly the same PID at exactly the same time--within the resolution of the timestamp granularity. The combined value suitably encoded (hex or base64) will be used as the prefix supplied to tempname() to generate the names for the temp. files.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Seekers of Perl Wisdom