tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <m...@filip.net>
Subject RE: JDBC Session Manager.
Date Fri, 27 Jun 2003 17:35:12 GMT
that is for the membership detection of the cluster,
session propagates upon each request is finished

Filip

> -----Original Message-----
> From: Angus Mezick [mailto:amezick@guidestar.org]
> 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:mail@filip.net] 
> > 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:amezick@guidestar.org]
> > > Sent: Tuesday, June 24, 2003 2:01 PM
> > > To: tomcat-user@jakarta.apache.org
> > > 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
> > > amezick@guidestar.org <mailto:amezick@guidestar.org>
> > > www.guidestar.org <http://www.guidestar.org>
> > >
> > > 
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > >
> > >
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message