Disclaimer:
I can see a security related reasons to do stuff like that. I've seen this approach a couple of times and various applications, so I can understand why such a requirement can raise. Of course I don't think its a good idea in general to implement stuff like that, but given the requirement, I'll share my thoughts and provide solutions.
Since you're talking about sessions here, I assume you're in the web domain.
IMO There is a couple of ways to address this issue.
Assuming, every client has an HttpSession assigned to it:
Upon the first call when the session is created, put the 'current time' right into it. Then create a Filter that upon the first request executed the aforementioned logic and upon each request compares the current time with the time that has been set during the first request. If the difference is less than allowed time - proceed the execution, otherwise force logout, delete the session and everything. I guess the user will be forced to reconnect after this.
Example:
Lets say the user is allowed to be logged in for 10 minutes
Then in any subsequent request in filter (pseudo code):
doFilter() {
// if its a first request:
if(httpSessionIsCreatedInThisRequest() && noFirstLoginTimeOnSession()) {
httpSession.put("FIRST_LOGIN_TIME", getCurrentTime())
}
else { // for any subsequent request
currentTime = getCurrentTime()
if(currentTime - getFromSession("FIRST_LOGIN_TIME") < 10 mins) {
// you can proceed
}
else {
logout()
//do whatever You Need Here: logout, destroy the session
}
}
}
This solution is good enough for simple situation, but for the distributed application is not enough (it doesn't scale). In addition, if you have many users, maintaining an HttpSession for every user is a significant overhead because HttpSession-s just not scalable enough, and you don't want a session replication, because its always a pain :)
Alternatively to HttpSession you can implement the same logic via Cookie, but I doubt that Security-Wise it's good enough. I mention this because I don't know any of your security concerns here.
More Scalable approach. Instead of using HttpSession, use some persistent key-value store/stuff like Redis server. Store all the information there.
Depending on the concrete backend technology you'll have an option to use a TTL assigned to each record in the database. You might know that, but for the sake of completeness of the answer: TTL (time-to-live) means that you specify the time when the object will be erased by the server (purged) automatically without your interference. So in this case you'll just need to check whether the object exists there. This can be done from many servers, because, assuming they're in sync, they don't share any information about the user in this case so this scales much better.
Now you've noticed that all these solution don't use timer at all. Timer can be expensive, if you use Java util timer per User it uses the thread under the hood. So having number of threads bound to the number of users is a bad idea IMHO.
You can utilize solutions like Quartz (which is a scheduling framework), but again, if you'll try to create different triggers for different users it will become a messy and non-maintainable code. Moreover if you have too many jobs/triggers, Quartz starts to lag and this is not what you want. Bottom line, I don't really believe you should use this in this particular case. Quartz is a good product, don't get me wrong, I just think that it doesn't suit your needs here.
