Bas, Thanks for your answer. I understand what you're saying and you're right. If I were designing the application now I'd do one of your suggestions.
But unfortunately we've written most of the code and these threads now depend on spring session beans. Right now B is pretty much the only viable option. And we may go ahead and implement it (or maybe the polling alternative). I'd like to repeat my question though, if only to gain some deeper understanding of what's going on under the hood. Is there any danger if we leave things as they are and we don't implement neither A nor B? What is going to happen to the session? Will it still be invalidated, maybe causing exceptions to the threads, or will it be kept around until the threads finish? And once they all finish, will it be released or not? Cheers Marios On Sat, Nov 23, 2013 at 1:26 PM, Bas Gooren <b...@iswd.nl> wrote: > Hi, > > I guess it depends on the lifecycle of those threads how I would handle > this. > Suppose the session is invalidated and destroyed, what should happen to > the threads? Do they continue (A) or do they need to stop (B)? > > A) In this case I would not depend on the session at all, if possible. > Simply copy the OAuth token to a private variable in your threads. > > B) Instead of the threads "polling" to see if the session is still there, > I'd turn things around. Keep track of sessions-and-their-threads somewhere. > Register a session invalidation listener, and when the session is > invalidated, you can run some code to neatly stop and clean up your threads. > > Met vriendelijke groet, > Kind regards, > > Bas Gooren > > schreef Marios Skounakis op 22-11-2013 23:45: > > Hi all, >> >> This is maybe a Spring question but as my app is a wicket app and I use >> this list regularly and everyone is very helpful I thought I'd ask here >> first. >> >> I have a RequestCycleListener which during onBeginRequest() conditionally >> spawns some background threads and runs them using an Executor. These >> threads need access to an oauth token which is stored in the session. So I >> create my threads in the RequestCycleListener, give them a reference to >> the >> wicket session and run them in the background thread. The threads also >> have >> a reference to Spring's session (via spring's >> RequestContextHolder.getRequestAttributes()/setRequestAttributes()). >> Actually the dependence on spring session is much harder to alleviate as >> they often need to access session scoped beans. >> >> I'm wondering what exactly happens if I try to invalidate the session >> (e.g. >> when the user logs out) while such a background thread is running. Is >> there >> a possibility for harmful side-effects? >> >> Should I consider adding code to my threads to periodically check that the >> session is still valid? After all they do have a reference to the session >> object, so this sounds feasible. >> >> If it matters at all, I'm using Tomcat. >> >> Thanks in advance, >> Marios >> >> >
