Bug when expiring session with non-in-memory SessionRegistry (concurrent sessions)?

[geoffreym]

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?

[Rob Winch]

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.

[geoffreym]

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.

I would argue that that does not seem to be consistent with the design. There is, for example, a refreshLastRequest method on the SessionRegistry.

[Rob Winch]

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.

Cheers,

[geoffreym]

Thanks for your feedback!