Martin, I understand this is getting a bit off topic so we could as well drop it.
I understand that the threads and session will eventually be garbage collected (go to /dev/null as you said). But this is not necessarily bad, is it? In my case these threads are updating an application-wide cache. So it is acceptable that they update the cache even if the session has been unbound, and when they are done they may as well be gc'ed. Am I missing something? Thanks Marios On Sun, Nov 24, 2013 at 1:13 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > Hi, > > > On Sat, Nov 23, 2013 at 2:11 PM, Marios Skounakis <msc...@gmail.com> > wrote: > > > 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? > > > > What happens is that you will keep a reference to a plain object that is > not managed by anything anymore. > I.e. your case is a normal memory leak. > Whatever you store in such session will go to /dev/null. > > I think you should consult with Servlet API - > > http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSessionListener.html > . > This listener will inform you when a new session is bound and when one is > destroyed. Your threads should work only with the currently active/live > sessions. > > > > > > 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 > > >> > > >> > > > > > >
