On Thursday 29 July 2004 10:41, Ara.T.Howard wrote:
> On Fri, 30 Jul 2004, Sean O'Dell wrote:
> > On Wednesday 28 July 2004 23:06, Lennon Day-Reynolds wrote:
> >> Sean: I like the idea of a seperate component that handles nothing but
> >> ID generation. Properly done, it could easily extend to other useful
> >> applications (sessions IDs for non-RDBMS-backed webapps, etc.).
> >>
> >> Now the only question is what underlying storage engine to
> >> use...Berkeley DB? CDB? Flat files? PStore?
> >
> > I would use a regular old file.  If you have a persistent layer, maintain
> > it internally as a native integer and write it out each time it's
> > incremented as text.  Re-load the value from the file when the persistent
> > layer first loads.
>
> this is alot trickier than it sounds: you will have locking issues since
> every thread/process will need to coordinate access to this file.  you can
> wrap a call to File#flock with a mutex, but this will fail with, for
> example, NFS mounted home directories.  for that you could use a mutex
> wrapped fcntl lock, but that will fail on certain OSes - like solaris.  you
> could use my lockfile class, which will work with threads, processes, and
> NFS filesystems, but that will greatly complicate matters...

A middle layer server would be able to use file locks and mutexes to 
coordinate access, which is what I advocated.

However, if multiple processes wanted to handle the file directly, they only 
need to lock the file at appropriate times.  I actually have a pretty large 
project right now that consists of multiple processes accessing the same 
files using file locks as semaphores.  It works very well, but I wouldn't 
have had much success with it if I hadn't written a module to manage the 
locks.

But for a single file it shouldn't be tricky.

	Sean O'Dell