It probably won't satisfy your needs, no. There are two fundamental issues with embedded implementation:
It does not support tab browsing. If the user loads the same screen on several browser tabs, two tabs accessing the same controller are going to compress the session attribute data for each other.
If users do not follow your “planned” navigation path, the call to setComplete() will be skipped and the object will hang indefinitely until the session ends and is cleared.
Number 1 may or may not be a problem, depending on how your application is created and what it does. (some things, like banks, intentionally prohibit use with multiple tabs anyway). But most users, who, as I think, will be able to edit user profile A on one tab and user profile B on another tab and not transfer one form to another screen.
Number 2 you could work with, always sending the screen to your own controller and then redirecting it after cleaning, but it works a lot if you are not building this path yet.
The good news is org.springframework.web.bind.support.SessionAttributeStore - a recognized extension point! You can provide any implementation that you like and enter it in the servlet of your dispatcher. You don’t even need to use a web session to store information if you want to avoid inflating its business objects. For example, you can put this actual repository in a back-end terracotta cluster and not worry that it is compatible with your clustering strategy.
-
And then there is always the Gamma option, if you really need true scalability: rework it into a RESTful strategy, which does not primarily rely on server state :)