am I allowed (without any sideeffects) to create and start a new Thread() from within a doGet() Method of a servlet? Or does this somehow leak ressources?
Is it valid to also pass the “Session” Object into the Thread to later save the result of my asynchronous processing (I will synchronized correctly) in the session? Or will this leak ressources when using the session “in indepedant threads”?
=> What would happen if the session meanwhile would be expired by the webcontainer as it has timedout and I will access it from my thread? Or would could this also lead to the sideffect, that storing the session in the thread will prevent the webcontainer from expiring the session at all (and therefore finally leak ressources as the sessions do not get cleared up)?
(I know there are other Solutions, like working with DB-(Job)Records, JMS or Servlets 3.0) but I need so solve the problem as described by spanning a new Thread within doGet.)
Thank you very much!!
Jens
First off, what you want to do will PROBABLY work. Depends on a whole bunch of things. But with a system with little load, few requests, etc., it will probably work fine.
Regarding your Session expiration issue, odds are “nothing will happen”. You will happily store and reference information that nobody else is looking at.
Naively, the server will expire the session, and remove the Session object from its internal map. Meanwhile, your thread will keep a reference to it, and won’t be the wiser of whether the Session is good or bad.
On a loaded server, the system might take the users Session information and serialize it out to disk. When the user comes back, it’ll read it back in. In that case, you’ll be referring to the “old, orphan” Session that, again, the User will never see again.
When your thread dies, the Session will Go Away along with the thread.
So, basically, as long as you have a single instance of the server, that you don’t cluster, that your server doesn’t swap out sessions, that the server doesn’t restart (this is another point where the server might save and restore sessions), and the session doesn’t time out — you should be good.
Yes, those are all limitations on your technique, it doesn’t make the technique wrong, it just constrains the implementation. If your application and service can work fine within those constraints, you’re golden, and don’t worry about it.