Improve data consistency documentation

[gianluca-sabena]

I have some questions about what data consistency guarantees spring boot session jdbc provides.

Suppose we have this scenario:

• A stateful session in a spring boot application with spring session jdbc. Every request updates the session.
• 2 containers running with the same application
• 1 database with jdbc driver
• A reverse proxy with round robin (No sticky session) A client making parallel requests to the server

Questions:

• When the first request hits Container A in order to reads a session from DB, is there a lock on the object?
• If there is no lock on read, but only on write operation, what happens if a second request hits container B before request on container A has saved the session?
• Do we have to assume a last-write-wins semantics? Probably yes based on this answer
• Can we have stale data read?
• If we look at this example (https://docs.spring.io/spring-session/reference/api.html) can I state that in order to reduce data inconsistency I have to reduce as much as possible the time between session read (session.getAttribute(...)) and session save (4)?

I suggest to improve the documentation to better explain what data consistency guarantee spring boot session has for the different back-ends. For example wildfly use infinispan to manage distributed cache and has a good documentation on this.

A possible workaround is to use sticky sessions (optional, can be enabled only when required) to have stronger data consistency. With sticky session some optimization are possible: reads come from jvm memory objects, writes to persistent storage can be async. See issue 6

Thank you for your help and feedback.

[vpavic]

• When the first request hits Container A in order to reads a session from DB, is there a lock on the object?
• If there is no lock on read, but only on write operation, what happens if a second request hits container B before request on container A has saved the session?

There's no locking done by Spring Session itself (only the underlying data store itself). Session repository implementations by default track delta of changes done to the session (take a look at org.springframework.session.SaveMode and its usages) so that each request persists only changes it contributed to the session - this largely minimizes (but does eliminate entirely) the chances for lost update problem.

• Do we have to assume a last-write-wins semantics? Probably yes based on this answer

Yes, but as explained above this is minimized by the way changes to the session are tracked. Also note that the linked issue is about Map backed session repositories and those aren't really meant for production use as they, among other things, lack logic of tracking changes made to the session.

• Can we have stale data read?

In highly concurrent environments, this can potentially happen.

• If we look at this example (https://docs.spring.io/spring-session/reference/api.html) can I state that in order to reduce data inconsistency I have to reduce as much as possible the time between session read (session.getAttribute(...)) and session save (4)?

Generally yes, but note that most session repository implementations offer the customization of flush mode (look up org.springframework.session.FlushMode and its usages).

---

In summary, this issue is probably one of the aspects that #1011 should cover so it effectively duplicates it. @gianluca-sabena I'd encourage you to write a brief summary in a comment over there and link to this issue.