--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> >Current page name and id are never stored in db, so > >different browser windows can be on different > >pages... > > > > I thought your session was all stored in MySQL. Why > are you putting > these in the session exactly? If these things are > not relevant to more > than one request (page), they don't belong in the > session. They should > just be in ordinary variables. You are correct, these items are in the session in the db. I meant that they weren't kept in long term storage in the db after the session ended like the default page id and user name are. The current page id/name is only relevent for an active session. Once a session is started current page is set to whatever the default page id is and will change as the user changes pages. The only reason I did this (as I recall) is that way I can get the page name once. > You should use a cache for that, rather than the > session. This is > long-term data that you just want quicker access to. Yes, that's exactly what I want to do. My main concern is long-term data that I want quicker access to. I can definitely get it all from the db, but that doesn't seem very efficient. > Template Toolkit caches the compiled template code, > but it doesn't cache > your data or the output of the templates. What you > should do is grab a > module like Cache::Cache or Cache::Mmap and take a > look at the examples > there. You use it in a way that's very similar to > what you're doing > with Apache::Session for the things you referred to > as global. There > are also good examples in the documentation for the > Memoize module. Great...exactly the kind of info I was looking for. I'll look at those. We are using a load-balanced system; I shoudl have mentioned that earlier. Won't that be an issue with caching to disk? Is it possible to cache to the db? > There are various reasons to use a cache rather than > treating the > session like a cache. If you put a lot of data in > the session, it will > slow down every hit loading and saving that data. > In a cache, you can > just keep multiple cached items separately and only > grab them if you > need them for this page. With a cache you can store > things that come > from the database but are not user-specific, like > today's weather. Thank you for all the excellent advice and explination(in this and other posts). Most of the info I'll be pulling is *very* user-specific...user name, which features to display on which page, what features the user gets by email, etc. What happens is the user logs in and then the username (greeting), the default page id (the user can create many pages with different features per page) and what features go on the default page are pulled from the database and the default page is displayed, as well as any "module" info. The "modules" will consist of a "pages" module with the names of all the pages the user has created (with links) and a "emails" module which will display all the features that the user is getting via email. These modules will be displayed on every page. You can see that almost everything is user-specific. Right now I'm storing the page names/ids in a hash ref in the session (the emails module isn't live yet), but I thought that I would change that and only store the module id and pull the names from the db (if the user hasn't turned off the module) with each page call. Thanks again for all the info! __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
