Consider adding event publishing hooks in JdbcOperationsSessionRepository

[vpavic]

Due to limitations of the underlying data store, JdbcOperationsSessionRepository has no session event publishing capabilities. However, since many projects do include a publish-subscribe broker of some sort, it could make sense to add hooks that would make use of that broker to route events to all members of a cluster.

With this change, JdbcOperationsSessionRepository would create session events and then pass them to strategy of some sort, which would be implemented by users if they wish to enable event publishing. JdbcOperationsSessionRepository would also implement some sort of message listener contract which would be responsible for using ApplicationEventPublisher to publish events locally.

What are your thoughts on this @rwinch? If you're open to this idea I'd like to implement it in time for 1.3.

[okohub]

+1

[ksanta]

Our project creates "policy locks" in the database so only one person can action a policy at one time. Policy locks are essentially a record in a table and have a link to a session id. When a session expires, we would like any policy locks associated with that session to be removed.

I understand that session events are not enabled because there is no way to replicate that session state between all the cluster members, but the whole point of us moving the session to the database is so that our cluster members become stateless; we do not have to wait for sessions to drain before shutting down an instance for deployment.

[joshiste]

Imho it's also worthy for collecting metrics on sessions: We want to collect session data (active count) on all of our instances and aggregate it in our monitoring. But the tomcat.sessions.active.current metric (from micrometer) always yields null because the the sessions are not managed by tomcat. And hooking in via the events/HttpSessionListener also doesn't work. (Also subclassing the JdbcIndexedSessionRepository is not possible because JdbcSession is package-private)

[vpavic]

@joshiste Metrics are probably something worth looking at from a higher level. A while ago I opened #1495 to consider adding Micrometer integration. Please track (and vote) that issue if you're interested.