Sergey Yaskov opened SPR-16306 and commented
I have the Spring MVC controller which handles AJAX requests from a user. I have the next 2 handler methods:
@PostMapping("/notifications")
void performLongRunningOperation() {
// some operation which may take about 10 seconds
}
@PostMapping("/cancel")
void cancel(SessionStatus sessionStatus) {
sessionStatus.setComplete();
}
The problem is that if cancel() finishes execution before performLongRunningOperation() finishes execution, then setComplete() has no effect. More precisely, setComplete() cleans the session up, but then the session unexpectedly gets restored to the state which was during execution of the performLongRunningOperation() method. This is the unexpected behavior.
To summarize: setComplete() method does not work properly in a situation when one do not know exactly the order in which the handler methods are going to finish execution.
Please see the link to the related StackOverflow question in the "Reference URL".
The reproduction project could be found here: https://github.com/yaskovdev/sandbox/tree/master/spring-session-sandbox
Affects: 4.3.10
Reference URL: https://stackoverflow.com/questions/46505612/spring-mvc-setcomplete-does-not-guarantee-the-session-cleanup
Comment From: spring-projects-issues
Juergen Hoeller commented
Even after reconsideration, there doesn't seem to be an easy solution for this. Since session attributes themselves are individual elements in one large HttpSession and not timestamped in any form, we could only solve this through additional attributes:
- either a kind of token that's set on retrieve (at the beginning of a request) and removed on updating (at the end of a request), with an intermediate cleanup removing the token and preventing the update;
- or a marker attribute that's added on cleanup, indicating that specific attributes have been cleaned up and shouldn't get re-updated... however, that's potentially an attribute added to an otherwise empty session, and it's unclear when to eventually remove it.
Comment From: spring-projects-issues
Rossen Stoyanchev commented
Shouldn't cancel actually cancel whatever performLongRunningOperation is doing?
Comment From: rstoyanchev
As mentioned by Juergen above this isn't straight forward to implement, and SessionStatus was really designed around a form POST workflow. The cancellation should rather probably await and/or cancel any ongoing operations, before completing the session.