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
