Re: RES: Nervous about Sessions ...

[David Whitehurst]

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" <[EMAIL PROTECTED]>
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
([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]