Re: Managing session state over multiple servers
hi,
AFAIK hidden fields will do it if that is what you asking..
now here's aquestion that has been driving me batty.. here goes i hope that i
have been descriptive enough. i have at the top of one of my perl program a
variable that is called.
$Mystuff = $field{'Mystuff'};
#the above contains the values that i want to inject into the open()
#immediately below that i try a ..
my $myparameters = param("Mystuff");
#why because the $Mystuff for some reason does not enter the open();
#i then simply plug further down in a open to a program .. $myparameters and
#it tells me basically that $myparameters is empty.. but i am
#hittinging inside the open();
#..ok so i do immediately do a ..
my $myparameters = $Mystuff
#but now the $myparameters no longer hits the open();
#but a print statement below tihs open() gets 'real values' for the
#$myparameters..
#waht i am trying to do is get $myparameters to equal the $Mystuff and put into
#the open call as real values parameters..
Regards.
Managing session state over multiple servers
Hi: We're planning on migrating to an Apache::Session + mysql approach for managing session state, for a large-ish site hosted on multiple servers. While there have been many useful discussions on this list concerning the technologies involved, I haven't seen many war stories from the field, as it were. I have some specific questions - hopefully someone out there has had to address these issues and may have some good advice. a) If your site runs on multiple servers, do you attempt to cache session state records on the web server for any length of time after they are retrieved from the DBMS ? and if so, how do you handle cache consistency across all your servers - (we have rather blind load balancing hardware in front of our server farm with no way of implementing any kind of server affinity that I am aware of) b) Does anyone have redundant database servers ? If so ... are there any implementation gotchas ? and if you have a single server, how does session management work when it goes down ? (I'm pretty happy with the hardware - Suns - which we have, but a disk can go at any time) c) This is more of a mysql question When do people consider a session to have expired ? and what is the best strategy for deleting expired sessions from a database, especially given that mysql's table based locking seems to leave a bit to be desired if you're trying to mix update operations with a big SELECT/DELETE to purge expired sessions ? TIA - Simon - Simon Rosenthal ([EMAIL PROTECTED]) Web Systems Architect Northern Light Technology 222 Third Street, Cambridge MA 02142 Phone: (617)577-2796 : URL: http://www.northernlight.com "Northern Light - Just what you've been searching for"
Re: Managing session state over multiple servers
Simon Rosenthal [EMAIL PROTECTED] wrote: b) Does anyone have redundant database servers ? If so ... are there any implementation gotchas ? and if you have a single server, how does session management work when it goes down ? (I'm pretty happy with the hardware - Suns - which we have, but a disk can go at any time) Sun (and most other server/disk providers - e.g., SGI, NetAPP) provides a volume manager that can handle RAID volumes. If you have a spare disk in the system and a disk goes bad in the volume, you can take the bad disk out, put the spare in, and then replace the bad disk at a convenient time. The machine has to only be down for the hardware replacement then (Sun server), not at all (SGI disk array) or quiesced for a few seconds (NetApp). Disclaimer -- I am not an employee of any of the companies mentioned, nor am I endorsing any particular product or company. These are the systems that we have on the floor. I would suggest Apache::DBI to have persistant connections to the database and a fast local network to reduce latencies, though that's probably not the largest source of them. -- James Smith [EMAIL PROTECTED], 409-862-3725 Texas AM CIS Operating Systems Group, Unix
Managing session state over multiple servers
Hi Simon,
This is not an answer to any of your questions, but your mail reminded
me of a "gotcha" relating to Apache::Session and Apache::DBI that is
probably totally obvious to the gurus on this list.
When Apache::Session::DBI connects to a database, it calls:
$self-{dbh} = DBI-connect(
$datasource,
$username,
$password,
{ RaiseError = 1, AutoCommit = 1 }
);
If you use Apache::DBI, make sure that you call "connect" with the
same arguments as above in your other scripts or you will find
yourself with more than one connection/process to the database, which
may not be your intention. I spotted this by running "httpd -X" and
noticing that it would spawn a second db connection whenever a session
was created.
Hope this helps somebody!
Rob
Re: Managing session state over multiple servers
Hi there, On Fri, 17 Dec 1999, Robert Locke wrote: If you use Apache::DBI, make sure that you call "connect" with the same arguments as above in your other scripts or you will find yourself with more than one connection/process to the database, which may not be your intention. See the Guide, `Opening a connection with different parameters'. 73 Ged.
Re: Managing session state over multiple servers
All hail the Guide! :-)
However, I would like to say that Apache::Session::DBIStore does the
following:
$self-{dbh} = DBI-connect(
$datasource,
$username,
$password,
{ RaiseError = 1, AutoCommit = 1 }
);
so, if, somewhere else, you use a connection string that, for example,
does NOT include:
"{ RaiseError = 1, AutoCommit = 1 }"
then a separate connection will be initiated. That was the point I
was trying to make.
Also, re: the Guide, exactly how does one go about changing a
parameter like "LongReadLen"? Should one set it and then reset it to
its original value, something like:
$longreadlen = $dbh-{LongReadLen};
$dbh-{LongReadLen} = 50;
[do your stuff]
$dbh-{LongReadLen} = $longreadlen;
Thanks!
Rob
Re: Managing session state over multiple servers
On Fri, 17 Dec 1999, Robert Locke wrote: If you use Apache::DBI, make sure that you call "connect" with the same arguments as above in your other scripts or you will find yourself with more than one connection/process to the database, which may not be your intention. I spotted this by running "httpd -X" and noticing that it would spawn a second db connection whenever a session was created. Actually, this whole thread reminds me of a reverse-gotcha to the one quoted above. We needed to run without AutoCommit (doesn't everyone?) and have the ability to commit/rollback manually. BUT, we were using the SAME centralized connect subroutine in our session code (that utilized Oracle as a backing store). So, if any session data was squirreled away in the middle of another database transaction, we got a premature commit on the non-session SQL. This took a while to debug! :-) So, sometimes you WANT to have different connections, which is how we solved this problem. -- -- Tom Mornini -- InfoMania Printing and Prepress
