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]
