RES: RES: Nervous about Sessions ...
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:[EMAIL PROTECTED] Enviada em: quarta-feira, 27 de abril de 2005 17:34 Para: Will Hartung; Tomcat Users List; [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Enviada em: quarta-feira, 27 de abril de 2005 15:48 Para: Tomcat Users List; [EMAIL PROTECTED]; Paulo Alvim Cc: Tomcat Users List Assunto: Re: RES: Nervous about Sessions ... From: Frank W. Zammetti [EMAIL PROTECTED] 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 ([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]
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]
Re: Nervous about Sessions ...
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]
Re: Nervous about Sessions ...
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]
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: [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]
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]
RES: Nervous about Sessions ...
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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: Nervous about Sessions ...
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:[EMAIL PROTECTED] 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: [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: Nervous about Sessions ...
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]
Re: RES: Nervous about Sessions ...
From: Frank W. Zammetti [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: Nervous about Sessions ...
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 [EMAIL PROTECTED] 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 ([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]
Re: RES: Nervous about Sessions ...
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]
Re: RES: Nervous about Sessions ...
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]
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:[EMAIL PROTECTED] Enviada em: quarta-feira, 27 de abril de 2005 15:48 Para: Tomcat Users List; [EMAIL PROTECTED]; Paulo Alvim Cc: Tomcat Users List Assunto: Re: RES: Nervous about Sessions ... From: Frank W. Zammetti [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: Nervous about Sessions ...
From: David Whitehurst [EMAIL PROTECTED] 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