Oh, I missed one comment from Daniel before (embedded and I did not see on the
first pass, sorry).
No, you don't know the application so I would like to explain that some information kept
in the "shared application" beans is very static, needs to be loaded from the
DB and is used everywhere by every user. The number of hits to the DB would quadruple (at
minimum) without these small tables being in memory. I waste maybe 5k of memory to reduce
DB use in an active system and speed up user response time. This would be silly for a
system that it NOT active.
On Monday, January 13, 2014 8:38 AM, Ray Holme <rayho...@yahoo.com> 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 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.
Soooo - here is the question:
I would like to allow serialization, but tell Tomcat that certain beans should
NOT be resurrected without me getting warnings in the log file when I don't
mark them as serialisable.
IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?
Right now, I have stopped warnings but caused other problems.
On Monday, January 13, 2014 8:08 AM, Daniel Mikusa <dmik...@gopivotal.com>
wrote:
On Jan 12, 2014, at 8:45 AM, Ray Holme <rayho...@yahoo.com> 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.
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
