Provide a findAll endpoint on SessionRepository

[bcecchinato]

It would be nice to have the possibility to retrieve all sessions on a repository. This would allow for instance to make operations on sessions in non-http requests (batchs for instance).

One use case could be the use of the new endpoint with actuator, to display the count of sessions on every instance of an application (compared to local count of HttpSession).

Regards,

[rwinch]

@bcecchinato Thanks you for your feedback!

One of our goals is to keep the APIs we provide rather light. This makes it easy for providing additional implementations. Many of the data stores are key value stores and have certain limitations. For example, paging the results can become tricky, finding by properties can be tricky etc.

I'm not saying we can't or won't do this, but adding new APIs is something we will do with strong reservation for the reasons listed above.

It would be nice to have the possibility to retrieve all sessions on a repository. This would allow for instance to make operations on sessions in non-http requests (batchs for instance).

Can you explain why you need findAll for non-http requests?

One use case could be the use of the new endpoint with actuator, to display the count of sessions on every instance of an application (compared to local count of HttpSession).

This makes sense.

[bcecchinato]

@rwinch Thanks for the quick answer.

Can you explain why you need findAll for non-http requests?

My use case is the following : I have an administration website, that will display all the sessions (whatever the status). We also have the possibility to "kill" a session. This is what I mean by "non-http requests". Instead of retrieving a complete list of all sessions, maybe a list of all ids should be more simple to handle (and then a loop on SessionRepository#getSession).

But I do agree that paging would be a huge pain to implement.

Maybe my way of thinking is wrong. As this is a specific request, I might end up using my own implementation (using RedisOperations, or Hazelcast), with some kind of wrapper over spring-session.

[rwinch]

@bcecchinato Can the admin page require searching by the username? Most likely you won't identify the session to kill by the id anyways right? If so, we support finding sessions by username See http://docs.spring.io/spring-session/docs/current/reference/html5/guides/findbyusername.html

[rwinch]

@bcecchinato PS If you put together an actuator endpoint for killing sessions, I'd love to see that contributed!

[bcecchinato]

@rwinch

Can the admin page require searching by the username? Most likely you won't identify the session to kill by the id anyways right? If so, we support finding sessions by username See http://docs.spring.io/spring-session/docs/current/reference/html5/guides/findbyusername.html

I didn't planned to make a proper search by username. My idea was to display session attributes (like a table with static fields). I haven't finished to review what I will implement so far.

PS If you put together an actuator endpoint for killing sessions, I'd love to see that contributed!

I might have a look on this as it could interest more people.

[rwinch]

@bcecchinato I've actually planned on such a feature (to destroy sessions). However, it would require searching by username. This would ensure paging wasn't a problem (in most cases) since any one user is unlikely to have more than 100 connections (hopefully quite a few less).

I also have a prototype of changing log levels by username. This would be good for troubleshooting a specific user's problems. It would also be added to the actuator endpoint.

I'd really encourage you to do an actuator endpoint that operates by username. I know the community (and I) will love it!

[rwinch]

I created #407 and #408 to document these ideas. Again, I'd love for you or anyone else to jump in and work on them. I know the community will be very excited for them!

[rwinch]

Closing this issue as we don't plan on adding a findAll endpoint. User's can implement this themselves if they really need it, but it won't scale in most situations since paging is necessary and not supported by lots of the data stores