All,
Thanks for the helpful replies - I'm totally new to the apache world so
being a bit gun-shy on trying a persistence framework off the bat, what I've
done instead is have a single script, which based on a hidden field in a
form, figures out where execution should resume, and for every re-invocation
of the script, the data structures would (should?) be reloaded anew.
I have however now run into segmentation faults if I use the back button and
resubmit a form (for what reason I dont know). Dumb, but users will be also
so I have to be prepared somehow for it.
So, my *new* question is, (and I've got the hardcopy of the mod perl book so
if theres a chapter I need to read, just point it out) how are my data
structures being created/destroyed etc.., that is, for each invocation of
the script (as it progresses through my 'phases' or more unpredictably a
back/resubmit) is there not a new process assigned to each invocation, and
thereby seperate in-memory locations for those (redundant but safe) data
structures ? (which should avoid memory corruption)
Reading posts on segfaults makes me want to avoid them at all costs..
naturally..
-=M=-
p.s. when does a mod_perl proc die? i.e. when is that memory finally freed
up from one of my invocations/submissions? Since one of mod_perls benefits
is the compiled script is always in memory - could that somehow mean theres
'old data' for lack of a technical term still around? I dont want to
introduce memory leaks through ignorance either..
On 5/23/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
Mark-
you can not ensure that in-memory structures will be processed by the
same server/child, let alone be available to another script.
You'll need to find an inter-process store for your persistent item
if you're using something that provides for sessions ( ie
Apache::Session ) you can just stuff the data in there.
Otherwise Your best options are:
an RDMBS
a memcached store
If you are only using 1 server , you could use a local storage option:
some shared db store ( like berkley db , or a dbm )
a flat-file store
a tied file
one of the shared memory modules ( like FastMMap )
If you're only on 1 machine and can't use a session, i'd suggest
using an rdbms like mysql, postgres or sqlite. the advantage is that
you can run a quick cronjob that deletes keys that have been inactive
for 30minutes or so.
There is one ugly other option -- you could turn your data structures
into a serialized form, and either enccypt or digitally sign them,
and then have them sent back to the server and processed. you see
that a lot in asp pages. its damn messy and causes a ton of excess
bandwidth and processing power. pages with 2k of content quickly
have 130k of session data in them. i'd highly recommend against it.
On May 23, 2007, at 6:12 PM, Mark Henry wrote:
> Hi,
>
> I've done a decent amount of work in a particular script which
> reads a (flatfile) database, builds some data structures (hashes of
> arrays of arrays) does some processing and spits out a form.
>
> I then want the user to choose some values on the form, submit it,
> then I would act upon that, ultimately updating the original data
> structure and writing out the mods - sounds pretty standard..
>
> My question is, if I choose to handle the form submission
> (action="...") via a second (etc. etc.) script, how do I ensure my
> in-memory data structures will be available to that other script?
>
> I'm new to cgi/mod-perl, though I gather one could submit back to
> the same script - though this sounds like a pretty unscalable
> operation over the long haul, that is having *all* code in one script.
>
> Can someone point me down the right path? I have a feeling
> packages might have something to do with it - all my variables/
> structures are lexically scoped as is..
>
> I apologize if this is not the right forum, but I am using mod_perl!
>
> Many thanks,
>
> Happy Star Wars 30th!
>
> -Mark
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
