To make the long and short of it. Nothing in my application(s) should LIVE over 
a restart.

So serialization does NOT make sense for me at all. Users timeout after 
inactivity too which otherwise might be a good reason for using it (maybe it 
would be fine there as the timeout is pretty long).

However I very much appreciate your explanation. I was employing ONE totally 
static bean for constants, Utilities, (many could change during run time - e.g. 
debugLevel) and general purpose methods that are useful to lots of beans (e.g 
cleanNquote makes a string ready for SQL insertion). I HAD BEEN using another, 
Application,  to keep track of application dependent Vectors for quick look up. 
Using your example, these two could be combined and I would NOT need to pass 
around a handle to the bean called Application in my own version of UserInfo 
(as an object without class for compilation purposes - I use javac not a tool 
to build so cyclic compile problems must be handled carefully). I could just 
use the one independent static bean - Utilities and simple Java imports - MUCH 

On Thursday, January 16, 2014 5:45 PM, Christopher Schultz 
<> wrote:
Hash: SHA256


On 1/12/14, 8:45 AM, Ray Holme wrote:
> [S]erialization causes some problems in apache-tomcat-7.0.35
> 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).
> To solve this problem, I stopped serialization. This solved the
> problem.
> From the notes I got from others (thanks Mark and ...):
> serialization can be stopped by putting this in many places - here
> is one: appname/META-INF/context.xml
> <Manager pathname="" />

Can I venture a guess as to one other important detail you have left
out? It sounds like some of the objects you are putting into the
user's session (HttpSession: the stuff getting serialized to disk
across web application reload or Tomcat stop/start) may have
references to those application-scoped objects. Here's an example of
what I mean:

public class GlobalBean
  implements Serializable

public class UserBean
  implements Serializable
  private GlobalBean _global;
  public UserBean(GlobalBean gb)
    _global = gb;

... in your webapp's ServletContextListener:

init() {
  ServletContext application = getServletContext();
  application.setAttribute("globalBean" new GlobalBean());

... in your servlet:

doGet() {
  ServletContext application = getServletContext();
  GlobalBean gb = (GlobalBean)application.getAttribute("globalBean");
  HttpSession session = request.getSession();
  session.setAttribute("userBean", new UserBean(gb));

If the above are all happening, then when you de-serialize the
UserBeans, they will de-serialize the GlobalBean instance along with
themselves. If your GlobalBean has to do a bunch of db access or
whatever to initialize itself, it will either have to do that on
deserialization to make itself sane, or it will be in a non-sane
state. In either case, you won't get the newly-created GlobalBean from
your ServletContextListener (or similar) and things may get ... weird.

If this is the case, and you don't really care about the user's
session info, then by all means: disable session serialization and be
done with it. If you need this to work -- or if you need your web
application's sessions to be distributable -- then you are necessarily
going to have to change something with your architecture in order to
get this kind of thing to work in a sane way. My recommendation would
be to pass a GlobalBean into any method on the UserBean that needs to
access it, rather than keeping a reference of any kind. It's kind of
like IOC except ... not really anything like that ;)

- -chris
Version: GnuPG v1
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

Reply via email to