• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SessionListener?

 
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

I am using a session listener class to retrieve a session attribute and then serialize it as shown below:



I was expecting that when I exited my browser, the session would close and my sessionDestroyed routine would activate, creating a customer.ser file. It did not! It seems the container decides when it will terminate a session and this is not instantaneous. Anyway, I started opening more sessions and finally some began to close (session destroyed appeared on my tomcat terminal) but I certainly did not get a serialisation file. Does anyone know why? I suspect it is something to do with deploying an application in Tomcat where you cannot access the file system as you can in a plain Java application. Can anyone confirm this?

regards
Simon
 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is an element in the deployment descripot

<session-config>
<session-timeout>mins</session-timeout>
<session-conifg>

this will tell the container when to kill the session.

Session won't be kill when you close the browser because
there is no way for the container to know you did so.

Also check the HttpSession object there is a couple of
methods to kill the session programatically.
 
Ranch Hand
Posts: 951
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

HttpSession session = event.getSession();
Customer custBean = (Customer) session.getAttribute("cbean");



Does these lines of code refer to the same session object which is destroyed by the container ?


Thanks
 
Ranch Hand
Posts: 1026
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Does these lines of code refer to the same session object which is destroyed by the container ?



Yes.

This is what HttpSessionListener api says.


SessionDestroyed:
Notification that a session is about to be invalidated.



This method is invoked before the session is destroyed so that you can do any clean up work.


I was expecting that when I exited my browser, the session would close and my sessionDestroyed routine would activate, creating a customer.ser file. It did not! It seems the container decides when it will terminate a session and this is not instantaneous.



As Ernesto Leyva has pointed the container has NO way to know when you closed the browser. So it will wait till the default time-out period of the container(Tomcat-30 min) (OR) the time-out limit set by you using the setMaxInactiveInterval(int limit) (or) configuring in web.xml before calling the sessionDestroyed() method.
 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the comments guys, I now realise that I should call the invalidate() method to speed things up, but the real point is that the sessionDestroyed method was finally called, as you say, probably because Tomcat timed out, but it did not do the serialisation - and my real question is why not? Anyone got a theory?
 
Ranch Hand
Posts: 220
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
why don't you put a trace in the try and catch block, so you'll know which part is being executed, that will clear your suspicions
 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My suspicion was that despite the code executing, there is an inherent restriction in the web server that prevents access to the file system and I sought confirmation of this fact. I did however, insert a print statement



and sure enough the serialisation code is executed but no customer.ser file appears anywhere.


 
Akshay Kiran
Ranch Hand
Posts: 220
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
have you searched ur entire context directory for the file?

try removing the "/" and run it, just might work- I'm guessing
also, put a line to close the streams and tell me what happens
 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

thanks for all the comments. Kiran, I did a search and found the file in C:\ and also in C:\Tomcat\bin. I guess this is because I tried it with and without the \ (as you suggested!) Sorry for misleading you all. The file was there, I just had no idea it would end up outside the application, that is in directories above the root!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic