From: "Ara.T.Howard" <ahoward@...>
Date: 2004-07-30T02:41:44+09:00
Subject: Re: Stupid ODBC!

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.
>
> 	Sean O'Dell

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...

in short, i think that if you move state out of the database you'll need to
write a database.  well, not really, but you have two choices:

   * coordinate access via a central server
   * coordinate access amongst all clients

the first is probably impossible/overkill and the second is very, very hard.

-a
--
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. 
|   --Dogen
===============================================================================