> Ah! That's how you maintain variables (or state) from one request to > another...via a database. And then it's fine to store a username, or > better yet, a session id as a cookie on the client side to > act as a key > to look-up into the database. There no other way for this > information > (or any variable, for that matter) to persist across requests by the > same user other than keeping some kind of information on the client > side? (Other than URLs.)
None that you would want to use, since it is private and needs to be protected. > I see, thanks! I was thinking of global variables or even <%init> > blocks to set and store variables, but each request (even within a > single persistent connection by the same client) is > independent and no > variable can exist across requests? Remember that your solutions need to be scalable. That means that if you get busy you might end up using multiple backend processes, if you're not already (most likely). You may even end up with fastcgis on separate servers, with multiple web servers in front of them. All of this means that you're unlikely to get the same perl process serving this user the second time they make a request. The direction I'm currently in favour of is using memcached for short term variable storage, rather than a database. G ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mason-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mason-users
