Feb 6th, 2013, 03:25 PM
Bug when expiring session with non-in-memory SessionRegistry (concurrent sessions)?
In ConcurrentSessionControlStrategy, when expiring the least recently used session, expireNow() is called on the SessionInformation object, but nothing is done to persist this to the SessionRegistry. This works fine for the default, in memory, SessionRegistry implementation, but, with a non-in-memory implementation, it appears that the session will never be expired in the registry. In fact, there is no interface on the SessionRegistry which would allow this to be persisted. Am I missing something, or is this an oversight?
Feb 8th, 2013, 09:19 AM
You could imagine that other implementations of SessionRegistry that might return a SessionInformation that overrides the expireNow() method to perform any sort of cleanup. For example, it might make a database call to remove itself from the database.
Feb 8th, 2013, 11:47 AM
I would argue that that does not seem to be consistent with the design. There is, for example, a refreshLastRequest method on the SessionRegistry.
Originally Posted by Rob Winch
Feb 8th, 2013, 12:04 PM
I can see your point that this is inconsistent. Most of the operations are actually on the SessionRegistry rather than the domain object. However, the opportunity for changing the interface in a passive manner has gone. There could be an opportunity to implement with a new API and make some adapters to allow it to work with the old API, but the priority of this is a bit lower due to the fact that there is a way to implement the request. Please feel free to create a JIRA as an enhancement. One way to expidite such an enhancement is to create a pull request. Please remember that we will need to be passive so that we do not impact other users.
Last edited by Rob Winch; Feb 8th, 2013 at 01:25 PM.
Feb 8th, 2013, 12:17 PM
Thanks for your feedback!