tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angus Mezick" <amez...@guidestar.org>
Subject RE: JDBC Session Manager.
Date Wed, 25 Jun 2003 12:09:10 GMT
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


Mime
View raw message