tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Mikusa <>
Subject Re: serialization and newest tomcat
Date Mon, 13 Jan 2014 14:14:32 GMT
On Jan 13, 2014, at 8:37 AM, Ray Holme <> wrote:

> OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining
session as login to logout of a USER as I mentioned before, perhaps you are defining this
as "while tomcat is up" - I can see either def.). These type beans are all fine, but I would
actually never want them serialized if Tomcat restarts as I would want the user to log back
in for a lot of reasons (but no damage would be caused if they were serialized).

I'm referring to HttpSession.

Any thing you store on the session through the Servlet API will be persisted by Tomcat when
it shuts down and restored when it restarts (unless you disable this behavior as you have).
 This allows you to restart Tomcat and not lose session data.

If you want to see what your application is storing in the session, take a look at the Manager
application.  It allows you to browse through active sessions and view what has been stored

> I am talking about java beans that are part of the "application" and shared information
available to all users. These MUST be initialized at startup (they are) and OLD serial copies
are defunct (dangerous as they cause crazy connections to happen) when tomcat is restarted.

Not following you here.  Tomcat only serializes what you put into a session (javax.servlet.HttpSession).
 Anything else is up to your application.

> Soooo - here is the question:
> I would like to allow serialization,

Ok.  Make sure any object you put into the session implements Serializable.

> but tell Tomcat that certain beans should NOT be resurrected

Certainly one option is to not put them in the session, but you do have other options.  See
last comment.

> without me getting warnings in the log file when I don't mark them as serializable.

They *must* be serializable.  Otherwise you're going to get an exception.  This is a requirement
of Java serialization.

> Right now, I have stopped warnings but caused other problems.

As I've mentioned, your beans must implement Serializable or they won't be able to be serialized
and you'll see error.  This is not an issue with Tomcat.  It's a requirement of Java serialization.
 Tomcat uses Java serialization to persist your session data between restarts so it inherits
this requirement.  

I would suggest that you look into how Java serializes your objects.  If you don't like the
default behavior, it provides you with the ability to control that process.  One example,
if you want to prohibit a field from being serialized you can mark it transient.


> On Monday, January 13, 2014 8:08 AM, Daniel Mikusa <> wrote:
> On Jan 12, 2014, at 8:45 AM, Ray Holme <> wrote:
> I haven't been following this thread, but I wanted to clarify a couple comments here
just to make sure someone reading this in the future doesn't get the wrong ideas.
>> serialization causes some problems in apache-tomcat-7.0.35
> No.  What causes problems is when application objects are placed in the session and they
are not serializable.  This happens because, by default, Tomcat will try to save your session
data when it restarts.  It does this by serializing the data to disk.  Then when it restarts,
it deserializes the data and restores the sessions.
> The only other reason why your sessions would need to be serializable is if you're using
clustering (i.e. you add the distributable tag to web.xml).
>> I have several applications and run on fedora linux. I have used many releases of
fedora and tomcat.
>> My applications are characterized by
>>     a) all use a DB (firebird)
>>     b) all use both jsp and java servlets
>>     c) all use transient java beans for a "round" of interaction (user request -
user response)
>>     d) all have 1 or more session java beans for each user (login - logout)
>>     e) all have 1 or more application beans (initialized at startup, can refresh,
passed around)
>>     f) all have an application specific jar and share a common code jar
>> Long ago I added serialization to almost all of the java beans to stop tomcat whining
in the catalina.out file. This worked just fine until the most recent tomcat release.
>> On my development machine, java changes build new jars and apache/tomcat must be
restarted to work right. Starting with the new release, problems with connections happened.
>> After research, I discovered that the applications were going nuts with connection
requests and xinetd was shutting down the connection factory service. It took a 30 minute
wait (or reboot) to fix this problem. My guess is that the application wide beans were not
only being made fresh as always happens (they use one connection each to initialize), but
that the serialized versions were coming back up and trying to refresh causing lots of strange
connections to be created (if one is not passed, one is made and there are many routines each
needing a connection).
> I'm not going to pretend to fully understand how your application works, but from what
I took of this explanation it sounds like your application is stuffing a lot of unnecessary
things into the session.  Limiting that or taking a closer look at how those objects are being
serialized is probably something you should consider.
>> To solve this problem, I stopped serialization. This solved the problem.
> This certainly works, however it's worth nothing that you'll lose any session data when
you restart Tomcat.  For development that's fine, but in production you might not want to
do that.  I guess it depends on your app and what's in the sessions though.
>> From the notes I got from others (thanks Mark and ...):
>> serialization can be stopped by putting this in many places
> The "many places" are context files.  There are several locations where you can configure
your application's context.
>> - here is one:
>>     appname/META-INF/context.xml
>>     <Manager pathname="" />
> Again, just watch out as this will prohibit Tomcat from saving session data on restart.
 In other words, all session data is going to be lost on restart.
> Dan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message