tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: lastAccessedTime vs. thisAccessedTime
Date Tue, 04 Nov 2008 17:48:18 GMT
I won't say I understand all the usages perfectly myself, but I also 
stumbled on this mess.

I made a few such changes our Tomcat in the session package in 
conjunction with changes to PersistentManagerBase, FileStore, JDBCStore, 
etc (as these do too much thrashing reading all sessions from 
disk/database on maintenance intervals rather trying to track which 
might actually be expired, etc).  [I provided patches but didn't have 
time to slice these up into lots of little patches.]

Rainer Jung wrote:
> Hi,
> I tried to understand the usage of lastAccessedTime (lastAT) vs.
> thisAccessedTime (thisAT) in Tomcat 6 (I suppost trunk is the same but
> didn't yet check).
> As I understand it, the two different timestamps get used, because when
> a request is associated with a session and asks for the lastAT it should
> get the previous access time, not the one related to this request itself.
> The way it seems implemented at the moment is:
> - if a request for some session is in the state of being processed,
> lastAT gives the previous access time and thisAT give the time resulting
> from the request itself
> - if no such request exists, thisAT returns the last access time of the
> session, and lastAT returns the time of the second to last request!
> Whenever we need a lastAT for a session for purposes not directly
> related to request handling for this session we use lastAT, although
> thisAT should have the correct semantics in this case.
> Places where we should replace getLastAccessedTime() by
> getThisAccessedTime():
> session/ could swap session out although a
> request for the session is concurrently being processed on
> manager/ idleness profile
> manager/util/ inside getUsedTimeForSession(),
> getTTLForSession(), getInactiveTimeForSession(). Those are used when
> producing lists with session information.
> ha/session/mbeans-descriptors.xml: should either expose both values or
> preferrably return thisAT as a lastAccessedTime, because the use case is
> not retrieving info for the own session while running a request.
> Places where I'm not so sure:
> valves/ not sure, whether the valve runs before
> access() updates the access times. If so, we should switch to thisAT
> here, if not, keep as is
> ha/session/ readSession() sets both to
> current time ?
> session/ maybe should store both values, but not sure
> where they get read in
> Remarks?
> Regards,
> Rainer
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message