Re: shared memory

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

Jonathan Vanasco wrote:
> 
> look into memcached -- http://danga.com/memcached/

Thank you for the link, I didn't know that module, and I'll keep it in 
mind for some other projects.
But it is slightly off the mark as far as the issue below is concerned.
Maybe it was my mentioning "data in tables" that was confusing.  My 
problem is not to speed up database access, it is to share data (stored 
in memory tables, or say arrays) between Apache children/threads.

> 
> On Mar 15, 2005, at 11:35 AM, André Warnier wrote:
> 
>> Hello list.
>>
>> Having looked hi and lo for definite information on the subject, found 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 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 by
>> an "abstract" document-id.  This document-id can be translated back to 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" 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é Warnier
>>
>