You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David Whitehurst <dl...@comcast.net> on 2005/04/27 11:31:14 UTC
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RES: Nervous about Sessions ...
Posted by Paulo Alvim <al...@powerlogic.com.br>.
Ok Jay,
But what about this JSTL recommendation:
(...)
javax.servlet.jsp.jstl.fmt.LocalizationContext lc =
new javax.servlet.jsp.jstl.fmt.LocalizationContext(bundle);
// This code just sets the lc variable - not serializable in the session
object
javax.servlet.jsp.jstl.core.Config.set(session,javax.servlet.jsp.jstl.core.C
onfig.FMT_LOCALIZATION_CONTEXT,lc);
(...)
In this case we should have to extend that JSTL class...but it used to work
in TC 5.0.28.
Do you know why TC 5.5.9 doesn't accept it?
Thanks,
Paulo
-----Mensagem original-----
De: Jay Hulslander [mailto:jdh34@cornell.edu]
Enviada em: quarta-feira, 27 de abril de 2005 12:51
Para: Tomcat Users List
Assunto: Re: Nervous about Sessions ...
To store a Java Object in session (HTTPRequest or HTTPResponse), just make
any Object (POJO or something more complicated) implement
serializable. Keep in mind, you don't need to code an extra functions,
just add the implements serializable to Class definition.
-Jay
At 07:42 AM 4/27/2005 -0400, you 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: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Nervous about Sessions ...
Posted by Jay Hulslander <jd...@cornell.edu>.
To store a Java Object in session (HTTPRequest or HTTPResponse), just make
any Object (POJO or something more complicated) implement
serializable. Keep in mind, you don't need to code an extra functions,
just add the implements serializable to Class definition.
-Jay
At 07:42 AM 4/27/2005 -0400, you 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: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: RES: Nervous about Sessions ...
Posted by Will Hartung <wi...@msoft.com>.
> From: "David Whitehurst" <dl...@comcast.net>
> Sent: Wednesday, April 27, 2005 9:15 AM
> Will , I do editing application software for clients like BMW and
> Volkswagen, and my application had an issue where e.g. 2 records in
> 22,000 edits had the same data tied to different keys and different
> editors (users). I found that I was using a HashMap (not threadsafe,
> changed that) and I now ..I am wondering whether the use of java simple
> types (e.g. client, and user strings) in the session is a good idea.
Well, let's look at the problem.
Sessions are based on a JSESSIONID (typically) which is assigned to the user
when the session is created.
In a perfect world, the user will only be making a single, synchronous
requests to the server (meaning they'll happily wait until the request
returns before making another request). But, it's important to know simply
that sessions are tied to requests, so if you have several simultaneous
requests with the same JSESSIONID, then you have a race condition whenver
you interact with sessions (or any objects taken from sessions, for that
matter).
Next, though, is the Request itself. Requests are just like Sessions, in
that they can have arbitrary attributes. However, requests are unique. You
may get several simultaneous Requests all within the same Session, but they
all are unique Requests. So, modulo jumping through hoops to change the
behavior, you shouldn't have to synchronize anything when dealing with a
Request, or any attribute placed in it. Note, that sticking an object
fetched from a Session and placing it in the Request doesn't suddenly free
it if there's a chance another thread can get the same object from the same
Session.
If you're using the Session as a big global space to pass things around to
routines within the application, then you most certainly need to synchronize
access to those objects.
However, you mention that your behavior was manifesting across USERS. All of
those users should have their own unique Sessions.
So the question becomes, how did these Users get the same Object placed into
their Session?
A wild guess would be from a central cache.
Perhaps when you fetch a record, you cache it, and then return that
structure to the User, who then stuffs it into their Session for
manipulating. If another User accesses the same record, they may well get
the exact same object from the cache, and now you have two Users fighting
over the same object. You would get this even if access to the cache itself
is synchronized, as it doesn't effect the root object in question, just who
gets it first.
Here, you need to think about either cloning (to some arbitrary depth) your
cached object before returning them to the requestor, or just creating them
new copies.
Also, this suggests that you may have an even deeper problem of locking on
the database end. It sounds like you may have an issue that even if you get
two seperate copies for your two Users, you may well have the issue of one
user stomping on the changes of another. Most folks today use some scheme
for optimistic locking using a row version number, or timestamp, and making
sure that the version of the row you're updating in the database is the same
as the one you have, if not you can handle it however you want (note, this
can be the tricky part).
Now, none of this has anything to do with serialization. In fact,
serializing the object ends up creating new objects that are essentially not
shared. If two Users are sharing an object, and their Sessions get persisted
and then reloaded, they both end up with 2 new distinct objects, where they
shared one before.
As far as the basic Java types, Strings are immutable. Period. That's
enforced by the JVM. You can't change one behind the back of another user.
No race conditions with Strings themselves.
The real primitives (int, byte, char, etc.) are immutable. You can have two
threads trying to change the value of a primitive member variable of an
object, but that's the objects problem, not the primitives. If two threads
fight over the same primitive, one will win, and win completely. I don't
think you'll get half one int, and half of another int, but that's really up
to the CPU architecture as well as the JVM. (For example, I don't know if
you atomically assign a long (64-bit) value without the risk of it being
interuppted in the middle. I don't even know if Java can interrupt a thread
in the middle of a byte code execution or not (assuming byte codes are
atomic)). Frankly, I wouldn't worry about these at all.
The Java Objects like Integer, Boolean, etc, are EFFECTIVELY immutable, but
there's a catch. The methods on, say, Integer, don't allow you to change the
value of an Integer once it is constructed, but if you're playing some games
with introspection and reflection, it CAN be done. It, as a rule, isn't, but
it IS possible. I wouldn't worry about these either.
So, basically, it's the containers and regular classes you need to worry
about, and not the primitives themselves.
I would focus on a) how did two users get the same Object in their session
or b) how are users making multiple requests on the same session (why are
they doing this, is it common, etc.).
The problem isn't in the Session itself, nor necessarily in the corrupted
Object, but I think it's deeper in your application wherever you end up
getting your Object.
Knowing essentially nothing about your app, that's the best 2 cents I can
give at this point. I wouldn't worry at all about using the primitve types
(including String) in a Session. Note, though, that Dates don't count.
Regards,
Will Hartung
(willh@msoft.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: RES: Nervous about Sessions ...
Posted by David Whitehurst <dl...@comcast.net>.
Will , I do editing application software for clients like BMW and
Volkswagen, and my application had an issue where e.g. 2 records in
22,000 edits had the same data tied to different keys and different
editors (users). I found that I was using a HashMap (not threadsafe,
changed that) and I now ..I am wondering whether the use of java simple
types (e.g. client, and user strings) in the session is a good idea.
We are testing the synchonization of the Hashmap object Friday. So, I
am on a knowledge hunt to understand session fully. I use Tomcat 5
within JBoss 3.2.5 servers.
Thanks (I know I'm not supposed to do that so that's why the explanation)
David L. Whitehurst
Will Hartung wrote:
>>From: "David Whitehurst" <dl...@comcast.net>
>>Sent: Wednesday, April 27, 2005 8:05 AM
>>
>>
>
>
>
>>I heard something confusing in the reply. If Tomcat has a file caching
>>under load, how does Tomcat serialize the objects in session if the
>>client application isn't placing objects implementing
>>java.io.serializable everytime?
>>
>>
>
>It doesn't. It fails for that case.
>
>The real question is whether you care.
>
>If you're using the RAM based session manager that tries and saves sessions
>on Tomcat restart, then you ask yourself if you really care to save sessions
>over a restart? (I don't, you may though.)
>
>If you don't, then it doesn't matter if you have non-serializable data in
>your sessions.
>
>If you DO care about persisting sessions (for whatever reason, such as
>relying on a paging session manager), then obviously you need to make sure
>you store serializable data.
>
>The real point, though, is that the spec says that you can put an Object
>into the session. It doesn't say Serializable. So, if Tomcat for whatever
>reason, is doing something like:
>
>public void setAttribute(String name, Object value) {
> if (!(value instanceof Serializable)) {
> throw new BoomBoomException();
> }
>}
>
>Then, it's kind of adhering to the letter of the spec, but not really the
>spirit of the spec.
>
>It's fine to say that if you have Objects that are not Serializable in your
>Session, the session will not be persisted, if and when that happens, but
>it's another thing to limit the contract (since, in most case in the real
>world, most sessions are simply stored in memory and serialization is not an
>issue).
>
>Besides, it doesn't even solve the issue. You can put, say, an ArrayList
>full of objects that are not serializable, and it would pass this test, but
>fail later. The only real way to know if something is Serializable is to
>either reflectively crawl the objects contents and check, or simply try and
>serialize it and see. Any session manager that's serializing or crawling the
>Object every time you call setAttribute is going to, umm, politely, "suck",
>because of the performance hit. (Note, many failover session managers do
>precisely that -- serialize the new attributes immediately, but then, they
>pretty much have to don't they? But you knew that when you signed up for
>it.)
>
>So, better to document the behavior and adhere to the spec and let the
>programmer deal with the consequences of all that rope you're handing him.
>
>IMHO, of course, I'm not emperor yet. If I were, I could make an edict,
>until then...simple opinion :-).
>
>Regards,
>
>Will Hartung
>(willh@msoft.com)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: RES: Nervous about Sessions ...
Posted by Will Hartung <wi...@msoft.com>.
> From: "David Whitehurst" <dl...@comcast.net>
> Sent: Wednesday, April 27, 2005 8:05 AM
> I heard something confusing in the reply. If Tomcat has a file caching
> under load, how does Tomcat serialize the objects in session if the
> client application isn't placing objects implementing
> java.io.serializable everytime?
It doesn't. It fails for that case.
The real question is whether you care.
If you're using the RAM based session manager that tries and saves sessions
on Tomcat restart, then you ask yourself if you really care to save sessions
over a restart? (I don't, you may though.)
If you don't, then it doesn't matter if you have non-serializable data in
your sessions.
If you DO care about persisting sessions (for whatever reason, such as
relying on a paging session manager), then obviously you need to make sure
you store serializable data.
The real point, though, is that the spec says that you can put an Object
into the session. It doesn't say Serializable. So, if Tomcat for whatever
reason, is doing something like:
public void setAttribute(String name, Object value) {
if (!(value instanceof Serializable)) {
throw new BoomBoomException();
}
}
Then, it's kind of adhering to the letter of the spec, but not really the
spirit of the spec.
It's fine to say that if you have Objects that are not Serializable in your
Session, the session will not be persisted, if and when that happens, but
it's another thing to limit the contract (since, in most case in the real
world, most sessions are simply stored in memory and serialization is not an
issue).
Besides, it doesn't even solve the issue. You can put, say, an ArrayList
full of objects that are not serializable, and it would pass this test, but
fail later. The only real way to know if something is Serializable is to
either reflectively crawl the objects contents and check, or simply try and
serialize it and see. Any session manager that's serializing or crawling the
Object every time you call setAttribute is going to, umm, politely, "suck",
because of the performance hit. (Note, many failover session managers do
precisely that -- serialize the new attributes immediately, but then, they
pretty much have to don't they? But you knew that when you signed up for
it.)
So, better to document the behavior and adhere to the spec and let the
programmer deal with the consequences of all that rope you're handing him.
IMHO, of course, I'm not emperor yet. If I were, I could make an edict,
until then...simple opinion :-).
Regards,
Will Hartung
(willh@msoft.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: RES: Nervous about Sessions ...
Posted by David Whitehurst <dl...@comcast.net>.
I heard something confusing in the reply. If Tomcat has a file caching
under load, how does Tomcat serialize the objects in session if the
client application isn't placing objects implementing
java.io.serializable everytime?
Will Hartung wrote:
>>From: "Frank W. Zammetti" <fz...@omnytex.com>
>>Sent: Wednesday, April 27, 2005 10:59 AM
>>
>>
>
>
>
>
>>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?
>>
>>
>
>Conceptually, I guess someone could have changed the session to require
>serialization. Perhaps they did this to handle the new "cluster/failover"
>aware sessions.
>
>Tomcat has different session managers. A simple one that happily consumes
>heap until you run out, a more sophisticated version that funnels old
>sessions to disk and reloads them on demand, and then the failover aware
>sessions.
>
>But, even the generic base version would try to persist session between
>restarts.
>
>Finally, if you're having issues, you can always wrap you non-serialized
>items into a class that IS serializable, and either simply lie (so that if
>it actually TRIES to serialize it, it will fail and throw an exception), or
>mark the fields as transient so they won't serialize.
>
>There's also the option of digging deep into the Tomcat source code and just
>"fixing" it and remove that limitation, but that's rather drastic.
>
>Regards,
>
>Will Hartung
>(willh@msoft.com)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RES: RES: Nervous about Sessions ...
Posted by Paulo Alvim <al...@powerlogic.com.br>.
Hi,
TC 5.5.9 also crashes (not-serializable attribute in the session) when we
try to put a List in the session this way:
request.getSession().setAtrribute("myList",l.subList(pos,l.size());
-----Mensagem original-----
De: Paulo Alvim [mailto:alvim@powerlogic.com.br]
Enviada em: quarta-feira, 27 de abril de 2005 17:34
Para: Will Hartung; Tomcat Users List; fzlists@omnytex.com
Cc: Tomcat Users List
Assunto: RES: RES: Nervous about Sessions ...
Thank you very much, Frank...
I had to create the following class...
----------------------------------------------------------------------------
---------
import java.io.Serializable;
import java.util.ResourceBundle;
import javax.servlet.jsp.jstl.fmt.LocalizationContext;
public class PlcLocalizationContext extends LocalizationContext implements
Serializable {
public PlcLocalizationContext(ResourceBundle bundle) {
super(bundle);
}
}
----------------------------------------------------------------------------
-------------
...and "lie" to Tomcat. It's ok for us now! ;-)
PS> But I think that this change will cause many problems to Tomcat
Users...maybe this check should be a server.xml option.
-----Mensagem original-----
De: Will Hartung [mailto:willh@msoft.com]
Enviada em: quarta-feira, 27 de abril de 2005 15:48
Para: Tomcat Users List; fzlists@omnytex.com; Paulo Alvim
Cc: Tomcat Users List
Assunto: Re: RES: Nervous about Sessions ...
> From: "Frank W. Zammetti" <fz...@omnytex.com>
> Sent: Wednesday, April 27, 2005 10:59 AM
> 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?
Conceptually, I guess someone could have changed the session to require
serialization. Perhaps they did this to handle the new "cluster/failover"
aware sessions.
Tomcat has different session managers. A simple one that happily consumes
heap until you run out, a more sophisticated version that funnels old
sessions to disk and reloads them on demand, and then the failover aware
sessions.
But, even the generic base version would try to persist session between
restarts.
Finally, if you're having issues, you can always wrap you non-serialized
items into a class that IS serializable, and either simply lie (so that if
it actually TRIES to serialize it, it will fail and throw an exception), or
mark the fields as transient so they won't serialize.
There's also the option of digging deep into the Tomcat source code and just
"fixing" it and remove that limitation, but that's rather drastic.
Regards,
Will Hartung
(willh@msoft.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RES: RES: Nervous about Sessions ...
Posted by Paulo Alvim <al...@powerlogic.com.br>.
Thank you very much, Frank...
I had to create the following class...
----------------------------------------------------------------------------
---------
import java.io.Serializable;
import java.util.ResourceBundle;
import javax.servlet.jsp.jstl.fmt.LocalizationContext;
public class PlcLocalizationContext extends LocalizationContext implements
Serializable {
public PlcLocalizationContext(ResourceBundle bundle) {
super(bundle);
}
}
----------------------------------------------------------------------------
-------------
...and "lie" to Tomcat. It's ok for us now! ;-)
PS> But I think that this change will cause many problems to Tomcat
Users...maybe this check should be a server.xml option.
-----Mensagem original-----
De: Will Hartung [mailto:willh@msoft.com]
Enviada em: quarta-feira, 27 de abril de 2005 15:48
Para: Tomcat Users List; fzlists@omnytex.com; Paulo Alvim
Cc: Tomcat Users List
Assunto: Re: RES: Nervous about Sessions ...
> From: "Frank W. Zammetti" <fz...@omnytex.com>
> Sent: Wednesday, April 27, 2005 10:59 AM
> 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?
Conceptually, I guess someone could have changed the session to require
serialization. Perhaps they did this to handle the new "cluster/failover"
aware sessions.
Tomcat has different session managers. A simple one that happily consumes
heap until you run out, a more sophisticated version that funnels old
sessions to disk and reloads them on demand, and then the failover aware
sessions.
But, even the generic base version would try to persist session between
restarts.
Finally, if you're having issues, you can always wrap you non-serialized
items into a class that IS serializable, and either simply lie (so that if
it actually TRIES to serialize it, it will fail and throw an exception), or
mark the fields as transient so they won't serialize.
There's also the option of digging deep into the Tomcat source code and just
"fixing" it and remove that limitation, but that's rather drastic.
Regards,
Will Hartung
(willh@msoft.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: RES: Nervous about Sessions ...
Posted by Will Hartung <wi...@msoft.com>.
> From: "Frank W. Zammetti" <fz...@omnytex.com>
> Sent: Wednesday, April 27, 2005 10:59 AM
> 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?
Conceptually, I guess someone could have changed the session to require
serialization. Perhaps they did this to handle the new "cluster/failover"
aware sessions.
Tomcat has different session managers. A simple one that happily consumes
heap until you run out, a more sophisticated version that funnels old
sessions to disk and reloads them on demand, and then the failover aware
sessions.
But, even the generic base version would try to persist session between
restarts.
Finally, if you're having issues, you can always wrap you non-serialized
items into a class that IS serializable, and either simply lie (so that if
it actually TRIES to serialize it, it will fail and throw an exception), or
mark the fields as transient so they won't serialize.
There's also the option of digging deep into the Tomcat source code and just
"fixing" it and remove that limitation, but that's rather drastic.
Regards,
Will Hartung
(willh@msoft.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: RES: Nervous about Sessions ...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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:fzlists@omnytex.com]
> 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: tomcat-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RES: Nervous about Sessions ...
Posted by Paulo Alvim <al...@powerlogic.com.br>.
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:fzlists@omnytex.com]
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: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Nervous about Sessions ...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Nervous about Sessions ...
Posted by David Whitehurst <dl...@comcast.net>.
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: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Nervous about Sessions ...
Posted by Viorel Dragomir <vd...@wylog.com>.
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org