New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TaskExecutor with Session Scoped Bean [SPR-6479] #11145
Comments
Arjen Poutsma commented Not all of the Spring devs speak German, you know :). |
Andreas Höhmann commented Ok. I will explain the question in english ... Maybe there is a bug with the TaskExecutor because spring gets session information from ThreadLocal request attributes ... I guess. Sorry for my english ;) |
Juergen Hoeller commented There is unfortunately (still) no portable solution for this, since request objects may indeed be reused... Technically, a Servlet API request object is only guaranteed to be valid during the processing of the initial request (i.e. during the Servlet.service call in the original Servlet container thread that called the service method). And in case of a asynchronous Runnables, we are basically taking the request reference and passing it on to some other thread, which may or may not execute while the request object is still active in the original processing thread. Servlet 3.0 changes the semantics here a bit, although it isn't clear what that will mean for scoped beans yet: It certainly won't work out of the box but will rather require some special suspending and resuming of request processing, and special servlet configuration - which probably is overkill for simple async access to request and session attributes. In any case, up until Servlet 2.5, I'm afraid we are facing a fundamental platform limitation here. Our recommendation is to avoid the retrieval of request/session-scoped beans from asynchronous Runnables, in favor of obtaining those beans first and then passing them to the Runnable as constructor arguments. In other words, you could obtain the scoped bean instances in the original servlet thread, pass them to the Runnable instance, and then call TaskExecutor's execute(Runnable) method. Note that this requires raw scoped beans, i.e. no aop:scoped-proxy. Juergen |
Andreas Höhmann commented Hello Jürgen, one year later I have a similar problem ;) Is there a way/best practice to use session scoped beans in asynchronous tasks? Greetings from Leipzig |
spring-projects-issues commentedNov 30, 2009
Andreas Höhmann opened SPR-6479 and commented
Hello,
Wir haben in unserem Projekt den Effekt, dass im TaskExecutor ausgeführte Runnables die auf Session-Scoped Beans zugreifen "merkwürdige" Effekte im Jetty Umfeld geschehen. Alles in einem Satz erklärt ;)
Die Effekte sind kritisch da unterschiedliche User-Sessions vermischt werden.
Wir vermuten dass es durch die wiederverwendeten Request-Objekte von jetty dazu kommt.
Spring holt sich die Session Informationen aus den ThreadLocal Session-Request-Attributen.
In unserem Workaround kopieren wir den Request nochmal in den ThreadLocal bevor das Runnable
gestartet wird.
Ist jetzt die Frage ob es einen "allg." Weg gibt?
Grüße aus Leipzig
Andreas
Affects: 2.5.6
Reference URL: http://forum.springsource.org/showthread.php?p=271352#post271352
The text was updated successfully, but these errors were encountered: