Am 20.04.2011 um 07:41 schrieb Mukarram Baig:

> Hello Guys,

Hello,


I will not comment on the low memory feature, as I don't know it, but if you do 
not enable serialization on your session objects and shutdown or reload an app, 
the sessions will get persisted and you get an exception telling you that the 
session contains "non-serializable" objects. The session persistence is clearly 
written in the Tomcat log, does not happen behind the scenes.
I would suggest that this would also happen for the low-mem situation or should 
prevent Tomcat to unload your session at all.

Having said that, without further details, I can only give a hint as we have 
seen similar stuff, where we could not explain application behavior until we 
realized that the users are opening different screens in the same browser. Our 
application and especially session data handling was not prepared to cope with 
such a (natural, agreed) situation as different screens where using the same 
session objects. 

Maybe this could explain your NPEs?

Best regards,

Thomas


> I might be asking something that is very fundamental, but please bear with
> me here. We are using tomcat in a non-clustered environment. We put certain
> domain objects in the session and we have a heartbeat going which ensures
> that the sessions are valid in the lifetime of the screen. The domain
> objects are not serializable. We have randomly seen NullPointerExceptions
> thrown when accessing properties of these domain objects via the session. I
> had read about Tomcat deciding to serialize sessions when it thinks that the
> available memory is getting tight on some forum (
> http://www.coderanch.com/t/86379/Tomcat/Problems-disabling-Session-Persistence-Manager)
> but couldn't see the same in the servlet spec or documentation on tomcat's
> site. Wanted to verify if this is indeed the case? If yes, under what
> (approximate) conditions does tomcat decide to serialize sessions to disk
> and back? Overall, is the recommended approach to always make objects in the
> session serializable? Also, wouldn't it be great if a better exception like
> NotSerializableException be thrown rather than the user stumbling over null
> values and NPE's being thrown?
> 
> Thanks in advance!
> 
> P.S.: We are using tomcat 6.0.16 on Solaris in 64 bit JVM mode with Xms
> 1024m and Xmx 4096m.
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to