that is for the membership detection of the cluster, session propagates upon each request is finished
Filip > -----Original Message----- > From: Angus Mezick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 25, 2003 5:09 AM > To: Tomcat Users List > Subject: RE: JDBC Session Manager. > > > I REALLY need something that propagates on session change an not on some > type of timed mechanism. It looks like if I can get the session to > respond to an instance event I will be all set. (this close to hard > coding this bugger though) Or have I completely messed up how this > config works? It looks to me like there is some sort of polling going > on to save a session that has nothing to do with when a session is > changed and the request is completed. > > checkInterval="10" > mcastFrequency="500" > > --Angus > > > -----Original Message----- > > From: Filip Hanik [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 24, 2003 6:15 PM > > To: Tomcat Users List > > Subject: RE: JDBC Session Manager. > > > > > > just use session replication, it will take care of the > > problem of non sticky > > load balancing > > > > http://cvs.apache.org/~fhanik/ > > > > Filip > > > > > -----Original Message----- > > > From: Angus Mezick [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 24, 2003 2:01 PM > > > To: [EMAIL PROTECTED] > > > Subject: JDBC Session Manager. > > > > > > > > > This is NOT about the JDBC Session Store. > > > > > > Ok, now that is out of the way. I am working in an > > environment with a > > > cisco load balancer that is broken (or the sales rep lied). > > I can NOT > > > do sticky sessions reliably to save its life. So I implemented a > > > session manage in the iplanet server we were using to use a DB as a > > > session store. The only sessions in memory were the ones > > in use. All > > > sessions not associated with a currently processing request > > were stored > > > in the DB. This allowed us to have some VERY nice clustering > > > functionality without having to deal with ANY stickyness. > > On a request > > > as session was either inserted or selected from the db. > > Iplanet only > > > called the update method once at the end of the processing of a > > > servlet's service method in the NSServletRunner class. > > (when the request > > > input stream is closed) At this point the manager's > > update() class is > > > called. This is usually an empty class. > > > > > > I am wondering what the best way to implement the same > > functionality in > > > tomcat would be. My current though is to change > > > core.ApplicationDispatcher.invoke() to have the session > > from the request > > > call the manager's update method. (I see a whole lot more changes in > > > there) I would much rather have this event code be trapped by the > > > manager and then call the update. Anyone know how to go about this? > > > Should I have sent this to the developer's list? > > > > > > > > > support.fireInstanceEvent(InstanceEvent.AFTER_DISPATCH_EVENT, > > > servlet, request, response); > > > > > > > > > Angus Mezick > > > GuideStar - Philanthropic Research Inc. > > > 427 Scotland St. > > > Williamsburg, Virginia 23185 > > > PHONE: (757)299-4631 x35 FAX:(757)229-8912 > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > www.guidestar.org <http://www.guidestar.org> > > > > > > > > --------------------------------------------------------------------- > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
