>
> Has anyone noticed that sessions are the number one problem in every post
to
> this list?
>
> I know that sessions were my biggest problem with Embperl. I don't care
> what anyone has to say -- they are more difficult to setup than they
should
> be.
>
> Maybe someone who knows them in and out can write a White Paper on the
> subject? Describe the differences between locks, storage methods,
> differences between operating systems. What works and what doesn't?
> Versions of Apache::Session that work together?
>
I would highly appreciate if anybody could write something about session
setup. That's really a topic that must be explained in detail. I currently
don't have the time to do it own my own, but I would support anybody who is
willing to do so
Gerald
> I bet this would cut down Gerald's work of answering this mailing list.
>
> My thoughts,
> Joe
>
> -----Original Message-----
> From: ___cliff rayman___ [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 16, 2001 6:22 PM
> To: goEbusiness.com Mail Lists
> Cc: [EMAIL PROTECTED]
> Subject: Re: Sessions, MySQL, Embperl, ModPerl, more than VirtualHost
> =Problem!
>
>
> sounds to be like the EMBPERL_SESSION_ARGS are stored in global variables
> that are initialized either at child init time or the first time a request
> is made for that child,
> and are not reloaded on each execution of the request.
>
> not sure if it is in the docs, but obviously one session store interface
was
> assumed for each
> apache/perl child. you'll have to look at the source to see if that
> behavior is changeable.
>
> "goEbusiness.com Mail Lists" wrote:
>
> > Ok, I figured out what's happening....but not how to fix yet :)-
> >
> > Each of my web server processes seems to have a different
> EMBPERL_SESSION_ARG value...globally...in fact I think each Embperl Env I
> set is unique to each process.
> >
> > I added a print out of the pid ($$) to the bottom of each page, and each
> time the session ID changed, so did the PID.
> >
> > Then, checking the logs I see that the PID that I see on my screen (keep
> in mind I am getting the proper HTML output) is NOT in the log that
> corresponds to the site I requested...it's in the other site.
> >
> > So, I restarted apache and went to each site once...and recorded what
PID
> was in each log...each log held a different PID...not one PID showed up in
> both logs!
> >
> > I then refreshed on "other.domain2.com" for awhile until the ID changed.
> >
> > Lo and behold I hit a PID that only showed up in the Clients log file!
> Yet the EMBPERL_SESSION_ARGS (and every other ENV output, and other
Embperl
> debug output, like what file it processed, etc) is _correct_ for the site
I
> wanted, yet the ID was written into the Client's database (and log). So
it
> seems that the EMBPERL_SESSION_ARG is being ignore for the virtual for
some
> reason...whatever the PID handled _first_ sticks...even though the debug
> output reflects the proper output.
> >
> > Now to figure out why that is! :)
> >
> > Bill
> >
>
>
>
>
> ---------------------------------------------------------------------
> 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]
>
>
>
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
