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/PersistentManagerBase.java: could swap session out although a
request for the session is concurrently being processed on
manager/ManagerServlet.java: idleness profile
manager/util/SessionUtils.java: 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/PersistentValve.java: 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/SimpleTcpReplicationManager.java: readSession() sets both to
current time ?
session/JDBCStore.java: maybe should store both values, but not sure
where they get read in
Remarks?
Regards,
Rainer
---------------------------------------------------------------------
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]