I'm trying to use a cache to track current visitors to my site. As a simplistic first step, I'm just tossing the source IP into a cache. The semantics should be:
1. no explicit delete
2. cache automatically removes entries after 30 minutes of no activity (no put)
3. entries live forever, as long as they visit every 30 minutes
1. not count as "activity", so won't affect your semantics
2. will trigger Elements to be removed from the cache (the memory cache is not cleaned up routinely for performance reasons)
I have an application with similar requirements. Our implementation was to use a cache with eternal=true and we use the HttpSessionBindingListener to remove items from the cache (you could also use HttpSessionListener). This approach guarantees lifecycle synchronization with the HttpSession. Your approach is to try to replicate *in different code* the HttpSession expiry algorithm which has the possibility of failing. For instance, if a programmer uses HttpSession.invalidate() then the cache would hold a value that does not match a live session. Would that matter? Similar problem if a developer used HttpSession.setMaxInactiveInterval().
Whichever implementation, you may also want to think about Session persistence over application server restarts. Your app server may be able to (or even by default) preserve HttpSessions; in which case you may want to set the cache to *diskPersistent=true* (note that this is different from *overflowToDisk*).
Hope this helps, Andrew.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to use a cache to track current visitors to my site. As a simplistic first step, I'm just tossing the source IP into a cache. The semantics should be:
1. no explicit delete
2. cache automatically removes entries after 30 minutes of no activity (no put)
3. entries live forever, as long as they visit every 30 minutes
I think what I'm looking for is:
1. timeToLiveSeconds = 0
2. timeToIdleSeconds = 1800
3. check size with cache..getKeysWithExpiryCheck().size()
.. but I'm a little nervous that getKeysWithExpirationCheck will count as acitivy, thereby pushing off my idle expiration.
Can someone point me in the right direction here?
Thanks,
Andrew
getKeysWithExpirationCheck () will:
1. not count as "activity", so won't affect your semantics
2. will trigger Elements to be removed from the cache (the memory cache is not cleaned up routinely for performance reasons)
I have an application with similar requirements. Our implementation was to use a cache with eternal=true and we use the HttpSessionBindingListener to remove items from the cache (you could also use HttpSessionListener). This approach guarantees lifecycle synchronization with the HttpSession. Your approach is to try to replicate *in different code* the HttpSession expiry algorithm which has the possibility of failing. For instance, if a programmer uses HttpSession.invalidate() then the cache would hold a value that does not match a live session. Would that matter? Similar problem if a developer used HttpSession.setMaxInactiveInterval().
Whichever implementation, you may also want to think about Session persistence over application server restarts. Your app server may be able to (or even by default) preserve HttpSessions; in which case you may want to set the cache to *diskPersistent=true* (note that this is different from *overflowToDisk*).
Hope this helps, Andrew.