Add RedisOperationsSessionRepository flush immediately

[rwinch]

The default for RedisOperationsSessionRepository is to try and batch all the updates together. However, it would be nice if it allowed for writing immediately using a boolean flag.

Related #311

[VitaliiH]

Hi!
Could you help in understanding.
Let's pretend, we have a spring application, using spring-security and spring-session plugins. We do not store any own data in session.
We are worried, if attributes, placed into session by spring itself could be corrupted. Won't normal work of spring framework break because of this?
Should we care about it? Looks like we don't, because it's a spring plugin and this kind of circumstances we reviewed and considered.

[rwinch]

@VitaliiH Thank you for your comment. I'm not certain why you mention your concern on this issue. Is it related? This issue is discussing how if a session is created it will not be updated until after the request has completed. In some instances this may cause problems.

In general, Spring Session works well with the other Spring projects (i.e. Spring Security). If you have a specific problem, please create a new ticket and we can take a look.

[VitaliiH]

Well, I found here on github a few similar issues, which would have a one solution - make it possible to save changes in session immediately in Redis storage.
From my point of view, current issue is exactly the solution.

No, my problem isn't specific. The concern I have, is similar to this one: #311. One (long-running) thread/request starts, get some attribute from session and begin caclulation according to its value; while it's running, second one (instant) thread/request updates the same attribute in session. Then, when request one ends, it also updates this attribute but now it's value is wrong.

On our project, we have some legacy code with such behavior. We are removing it. But something similar could appear in 3d party libs.

I just want to be sure that strategy used is very close to behavior of standart HTTP Session (single web application). And also, I want to be sure that Spring itself or other libs won't fail because of this strategy.

[rwinch]

Currently the Spring Session attributes are only written if they are updated. This means that if you are only reading in the log running request, then there is not going to be a problem. You can find an outline in my comment #311 (comment)

If you are setting session attributes frequently, there is likely to be a race condition in high concurrency applications. However, this is no different than standard Servlet HttpSession.

The strategy differs from standard servlet in memory implementations. However, it will be very similar to servlet HttpSession when you enable clustered sessions.

[VitaliiH]

You are right, we should build our preferences on current behavior of HTTP Session.
Going deeper into problem, having different strategies looks more and more like different transaction isolation levels in DB. And what is strange, different approaches provides different strategies to resole race conditions and other problems.
Btw, when Milestone 1.1.0 is planned for release?

For me it looks tempting:

• to allow to flush session exactly before chaining to Controller's method, if there were any changes (additionally to flush at the request's end). That's how we could "separate" attribute changes inside framework from changes outside of it. As framework's actions are usually faster than custom code, we shouldn't worry about it anymore and concentrate on our code. It could be a compromise between instant flush and current strategy using cache.
• try to read atribute from Redis if attribute value is null. Just an extra reassurance.
  I'm going to continue investigate and try to implement these strategies.

Thanks for your answers!