lastAccessedTime vs. thisAccessedTime

[Rainer Jung <ra...@kippdata.de>]

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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: lastAccessedTime vs. thisAccessedTime

[Jess Holle <je...@ptc.com>]

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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>   


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