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
easier.
On Thursday, January 16, 2014 5:45 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ray,
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS2GDqAAoJEBzwKT+lPKRYOZcQAKEqbjKbJ3zYm8c6pShgltSj
IzJ0NwWEredE19MEB39p1JXRMP7AyfaPogyHLATQUyEcJWIP0MrWVDptRWXNlEYU
kbo3ybmJZGGn7MydLSzctzVZsLlgG58E+cta4WkShLtc72tTJq3Zv3T0XlH6RVaS
8LPuLluYwIGJ6OSPR4tH2/QDd26W6psIJdmqabh0Jbbw5rKaqr1l1+Ib2Yhj0XV1
W+LwAdZYc5RpHDvxKSsJd2lrql3yG2aRXAn2/BHxx0trO8ag25oBq9gfmezDOeyP
AwBWQI4ralPGr6cYDDKkgz5uILUsKWeoIneLXxeH9lN5qARm3le59waWPMnL/jjC
Md0BTIoLP8o1GAFboChDpVJWbLC029p4iLE7bzR1zzuz/g9dvsqcmKsT1mEEtdPi
usZ8sKg9X67KcYYfq2T0nKFtQTZF8YXUPjoUOPeC04p4VQsdi2saYLYJ7X2JPHDJ
A8odCpEm27u3aH7wUCb0EbQFqOce2KwCN3B9YPe0MBb709jBXmcb3Z00yQiZVecW
RaIC8/IU6seeOYG8PJTyLvNNLbcrRYU41mufmt+gx48EMZMPZe33yWa3mh4CBzaX
lTdscmOnRS4doOIjpA1n5wZgtUjcO91Q8rp23fov3WAE/FmC+OiQjBfUJ6UbcO21
1LsZanvSMh9ns8I8lgAU
=qSiT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
