Apache::Session and shared memory is probably what you want. Other options with Apache::Session might work as well. I've had very good luck using a MySQL server as the repository for session state info and setting up a HASH type table (which lives in memory, thus is very fast). However that method does mean you are serializing the session state, which is no good for things like database handles...
With database handles specifically I've gotten away with just using the "prepare_cached" mechanism of DBI. In that case not all instances have the SAME handles, but they do reuse them fairly efficiently. Its not a perfect system, and if you want to do cursor type things it won't work (ie, select, fetch 10 records, throw them out to client, then let client get 10 more on the next page hit, etc.). Problem is even the best systems don't really make this work very well anyhow. Clients often go away and don't come back, then you have a problem with database server holding large result sets on open statement handles for arbitrary time. The best solution to that really is to use session state to manage these things without open handles, so do the old go through the result set with "LIMIT 10" and always constitute queries to get results succeeding the old ones "WHERE recordid > $largestid" kind of thing. With Apache::Session you can at least hide the bookkeeping for that inside your session state code. On Wednesday 30 January 2002 23:36, [EMAIL PROTECTED] wrote: > Hi, > > My problem involves memory management between mod_perl processes. > I am running AxKit 1.5, with PerForm and the *new* session taglib. > I am using the Tangram framework for OO<->rdbms interface. This library > keeps cached versions of the db objects in memory. > > If I limit apache to one process, forms under PerForm stop working (why?). > If I don't limit, accessing an AxKit page starts at least one additional > apache process, so that I have at least two. Why ? Is this because AxKit is > large ? > > Ok, so now if I make a change in a form which runs in one mod_perl > instance, the other mod_perl instance doesn't know about it, and returns > me incorrect image of the db state. If I refresh my XSP page continously, > the serving mod_perl process alternates. > > I am able to observe that different mod_perl processes are involved > by doing $r->warn($$) from my taglib. > > I tried to take AxKit out of the equation, and write similar code with > plain mod_perl modules. I was not able to get it so that several mod_perl > processes are involved. In fact, only one mod_perl process got started > this time. > > How can I workaround this problem so that I can have a running site as soon > as possible ? What's the best way to go in the long run ? > > Thank you, > Boris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
