Optimize locking mechanism around storing flash attributes [SPR-11538]

[spring-projects-issues]

Rossen Stoyanchev opened SPR-11538 and commented

Currently AbstractFlashMapManager automatically locks on a static write lock when adding to or updating the underlying List<FlashMap> storage. The locking occurs at the start of a request, if there are expired FlashMap's (shouldn't be frequent, e.g. redirect that did not succeeded) or just before a redirect if the controller added flash attributes to be saved. Therefore locking is far from being used with every request.

Nevertheless locking could be improved in a couple of ways. First, it shouldn't be automatic in AbstractFlashMapManager. Some implementations like the cookie-based one coming in 4.1 (#13637) don't need it. Second, the lock can be more focused. The SessionFlashMapManager could use WebUtils.getSessionMutex(HttpSession) for locking on the HTTP session or a session attribuite (with HttpSessionMutexListener).

---

Affects: 4.0.2

Referenced from: commits 7399723

[spring-projects-issues]

Juergen Hoeller commented

Introduced getFlashMapsMutex template method, defaulting to the shared static mutex but overridden in SessionFlashMapManager to use the session mutex instead. Can also be overridden to return null, in which case no synchronization will be used.

SessionFlashMapManager also clears the session attribute now when the given FlashMap List is empty, avoiding any kind of storage overhead.

Juergen