-----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