On Mon, Feb 22, 2010 at 1:12 PM, Emmanuel Lecharny <[email protected]> wrote:
> Some thoughts about how to manage Idle sessions :
>
> In order to manage idle sessions, we should use a separated thread which
> will check periodically that the session has been used or not. We use a
> boolean flag which is reset when we read of write on this session, and
> switch to true when we check the session idleness : if the flag is already
> true, that means the session has been idle for at least one period.

> The thread will be wake up after having slept for the defined period
> (configurable globally), and will check every registered sessions.

I did something similar for a cache. Used an ScheduledExecutor to
iterate through entries and decide what to do.
It was ok, the only problem in my case was that I got CPU spikes each
time I iterated, but the num of entries were more than a million :-)

> The flag is named isIdle. It's an AtomicBoolean.
>
> Note : if we want to manage different idle times for different sessions we
> need to compute the sleep period for all the followed sessions, and also add
> a map of sessions to check accordingly to the periods. IMO, it's a bit over
> killing atm.

Ehcache has something similar for cache entries. Each cache entry has
last accessed timestamp and based on that calculation is made.
So if Session doesn't fit the criteria, we can safely leave the same.
Side effect would be that we may not have precise time for events, it
shall be when our Thread iterates through all of them. the other
alternative is to use Timertask, but it has overhead that we need to
kill the task each time the session is accessed and created a new
task. there is a lot of overhead in this approach, but it works fine.

> Q: should we manage two different IDLE states ? One for READ nod one for
> WRITE ? Not sure it makes sense...

Not sure if it makes sense, but whatever the case may be.. we fire a
session idle event, and either use a keep-alive functionality or kill
the session.
May be we can start with one event. Could any implementation be
interested in having distinct event? I am not sure


thanks
ashish

Reply via email to