> this would be a question for the user list, > take a look at the persistence manager > http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html
I kind of split on where to ask this, but it has actually very little to do with web content sort of things. It has to do with the basic underlying design of the HttpSession. Manager, and Store classes. What I'm asking is seemingly not easily done and I'm looking for some pointers on how one would go about doing it. The page you pointed me to is useful for instruction on how to use the Manager, but I am looking for information for the best way to augment the Manager's behavior. > > markw@mohawksoft.com wrote: >> I'm kind of looking for a couple pointers on a session management issue. >> >> I have a web cluster solution, originally designed for PHP, and am >> planning to use it in Java and Tomcat. It provides session locking for >> frames and concurrency and manages small to medium sized web clusters. >> It >> assume no session persistence at the web server level or session >> stickiness at the load balancer. >> >> The HttpSession system seems to assume that a session object lasts until >> it is no longer used, and then gets removed by the garbage collector, >> and >> that sessions are sticky to a particular machine. (Unless the cluster >> class is used and all sessions are replicated to all servers.) >> >> In essence, what I need is this simple sort of interaction: >> >> (1) Start session, get data >> (2) Web app processes data >> (3) End session, save data. >> >> >> It looks like to do this I would have to create a Manager class, a >> storage >> class and a session class. If there is an easier way, and, of course, >> one >> which is minimally invasive to the tomcat structure, I'd ove to hear it. >> >> I can optimize the code a bit on my end to incorporate a sequence number >> or something so that if a session is reopened by a process that has the >> most recent version, we can just use what's cached, otherwise we'd >> recreate the session object from the new data. >> >> Any ideas? >> >> Thanks in advance, >> >> Mark L. Woodward >> >> P.S. >> Of course, everything I do at this level will be available to the Apache >> org if it wants it. >> >> >> --------------------------------------------------------------------- >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
