Hi Paul,
No, I don't know of any changes... I'm actually wondering if this is a restriction the latest servlet spec places on objects in session... I tend to doubt Tomcat would be imposing such a restriction unless the spec indicated such a restriction... I myself might learn something here! :) Does anyone reading this know a definitive answer?
Frank
Paulo Alvim wrote:
Hi Frank,
I think this post is related to mine:
We had a few "non-serializable" objects stored in session in TC 5.0.28 but after migrating the app TC 5.5.9 is throwing
"java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute."
...when we try to put a non-serializable in the session. We are using a JSTL recommended form like:
(...)
javax.servlet.jsp.jstl.fmt.LocalizationContext lc = new javax.servlet.jsp.jstl.fmt.LocalizationContext(bundle);
javax.servlet.jsp.jstl.core.Config.set(session,
javax.servlet.jsp.jstl.core.Config.FMT_LOCALIZATION_CONTEXT,lc); (...)
Do you know about any changes related to that in TC 5.5.x?
Thank you!
Paulo
-----Mensagem original----- De: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 27 de abril de 2005 12:59 Para: Tomcat Users List Assunto: Re: Nervous about Sessions ...
There *technically* isn't any requirement that things you store in session be serializable. However, since some app servers use databases or file systems to persist session information, and that many times is implemented using serialization, and since serializable is usually (if not always) necessary in a clustered environment to replicate the session between nodes, you probably do for all intents and purposes only want to store serializable objects in session, just to "future-proof" your app.
Yes, you can store simple java types, and no, you do not *have* to use beans (although I think this is generally considered a best practice in most cases). If you do use beans though, you will probably want to make sure you only use serializable types in the bean, or mark them transient as Viorel mentioned, as per the point made in the first paragraph above.
But again, there's nothing that says you have to do any of this... if you KNOW you are only going to run on a single server and if you KNOW your app server is only storing session in memory, there is nothing that says any object you put in session, on it's own or by virtue of members it contains, must be serializable.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
David Whitehurst wrote:
If I use the "session" to store things, 1. Can I use simple java types? 2. Do I have to use Java Beans (extends serializable)?
David Whitehurst
Viorel Dragomir wrote:
Yes. But you can set some attributes of the objects as [ transient ] to not be serialized. So you don't have to make all objects in the package serializable.
Viorel Dragomir
. .. -------------------------------------------------------------------
----- Original Message ----- From: David Whitehurst To: tomcat-user@jakarta.apache.org Sent: Wednesday, April 27, 2005 11:31 Subject: Nervous about Sessions ...
Long ago a multi-client, multi-Oracle application was written using Struts. Recently, we had a 4 in 22,000 record data integrity issue. I found one client implementation that used prepared statements but the primary key was being used e.g. "update mytable set a= ?, b=? where pri_key = " + pkey + " ' "; ...whoa! I said, called the developer and we had a talk.
Then, I also found that where we use a HashMap object it is not synchronized. I suspect that was the data problem, i.e. two records saved by two different people, and the data was the same for the different records in the same Oracle second.
I'm looking for comments about the use of this HashMap on "requests" but I'm also nervous now where I use Strings in the "session" e.g. a clientname, username, etc. My concern started when I read the posts about the non-serializable objects in the session. Do all java objects placed in the session have to be serializable? Thanks,
David L. Whitehurst
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
