Re: shared memory

[prev] [thread] [next] [Date index for 2005/03/15]

look into memcached -- http://danga.com/memcached/

On Mar 15, 2005, at 11:35 AM, Andr=E9 Warnier wrote:

> Hello list.
>
> Having looked hi and lo for definite information on the subject, found=20=

> a
> lot but a bit confusing...
>
> Environment :
> Apache 2 / mod_perl 2 / perl 5.8.4+
> Windows and Unix(es)
> Apache mod_perl2 Handlers
>
> The basic question is : does there exist a platform-independent way =
for
> a bunch of apache2/mod_perl2 handlers to share information that would=20=

> be
> stored in some single shared memory area, assuming part of the
> thus-shared information changes from time to time ?
>
> More details :
> My application is a document storage and retrieval system, where
> documents are stored in some filing structure on disk, and identified=20=

> by
> an "abstract" document-id.  This document-id can be translated back to=20=

> a
> path by an algorithm based on information stored in a couple of simple
> tables.
> Most Handlers are retrieval agents serving document requests from
> browsers, for which they need access to the table information, to
> translate a URI-contained document-id, to a real path.
> The contents of the tables can change from time to time, because new
> documents are filed into the structure by ongoing filing processes.
> At the moment, the table information is stored in disk files, and each
> retrieval or filing process accesses it by flock-ing a "semaphore"=20
> file,
> reading the data, possibly updating the tables, then unlocking the
> semaphore file.
> I would like to replace this by tables held in memory and some access
> synchronisation mechanism between the various "child" or "thread"
> processes involved.
>
> At the moment, considering all the information I have found, the only
> methods that come to mind as being safe and relatively simple, would =
be
> 1) to create a separate daemon process acting as the "keeper of the
> shared tables", to whom the various Handler agents would talk via a =
TCP
> (or UDP) socket.
> or
> 2) to do this via DB or something similar (the tables are not that
> large, but I dislike this solution for various reasons)
>
> But are these really the only methods ?
>
> Thank you in advance.
> Andr=E9 Warnier
>