tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kutzinski <ku...@gmx.de>
Subject Re: persistence with sessions & distributable attribute
Date Thu, 18 Aug 2005 20:33:34 GMT
Question: why do you want to catch errors during serialization.
If you want to check that your attributes are serializable, you can use 
a SessionListener as I have shown. I can not think of any other reason 
why one would want to catch serialization exceptions.



Nishant Deshpande wrote:
> Thanks for the input.
> 
> Any idea how I can *catch* errors during serialization? I am guessing
> I will have to create my own PersistanceManager and override some
> functions..
> 
> Has anyone done this (or any other method of doing this)?
> 
> 
> On 8/17/05, Christoph Kutzinski <kutzi@gmx.de> wrote:
> 
>>I didn't say that distributables don't have to implement
>>java.io.Serializable. In fact they have to.
>>I just had the impression (from your first post) that you thought by
>>putting an non-serializable Attribute into a HashMap, the attribute
>>would become serializable, too.
>>
>>Example:
>>If you want to put a java.net.Socket into the session the session won't
>>be distributable because Socket isn't Serializable.
>>But if you put the Socket object into a java.util.HashMap (which
>>implements Serializable) and put the map into the session, the session
>>still wouldn't be distributable. This is because to serialize the
>>session the HashMap and ALL its fields must be serialized. Because the
>>Socket object is now part of the map, this won't work.
>>
>>Serializable is just a "marker" interface, i.e. the class just
>>"declares" that is it serializable.
>>You should read the Java Tutorial (somewhere in the JDK docs).
>>There is explained what Serialization really means.
>>
>>Christoph
>>
>>Lintang JP wrote:
>>
>>>I'm referring to this document on :
>>>http://www.onjava.com/pub/a/onjava/2004/04/14/clustering.html?page=2
>>> The words "Serializable" here would mean for session replication, right ?
>>>CMIIW.
>>> On 8/17/05, Christoph Kutzinski <kutzi@gmx.de> wrote:
>>>
>>>
>>>>Hi Nishant,
>>>>
>>>>where did you read that <distributable> will *enforce* serializability?
>>>>AFAIK <distributable> "only" means that your sessions can be distributed
>>>>to different tomcat nodes (i.e. a cluster). It doesn't enforce anything,
>>>>you have to make sure that your session attributes are serializable by
>>>>yourself.
>>>>
>>>>I've done this for my testing environment with a SessionListener:
>>>>
>>>>public class SessionListener implements HttpSessionListener,
>>>>HttpSessionAttributeListener {
>>>>
>>>>private ObjectOutputStream stream = new ObjectOutputStream(new
>>>>OutputStream() {
>>>>public void write(int b) {}
>>>>});
>>>>
>>>>public void attributeAdded(HttpSessionBindingEvent evt) {
>>>>
>>>>if (LOCAL_DEBUG) {
>>>>// try to serialize attribute
>>>>Object o = evt.getValue();
>>>>synchronized (stream) {
>>>>try {
>>>>stream.writeObject(o);
>>>>} catch (IOException e) {
>>>>System.err.println(evt.getName() + " is not serializable: " +
>>>>e.getMessage());
>>>>e.printStackTrace();
>>>>}
>>>>}
>>>>}
>>>>}
>>>>
>>>>...
>>>>}
>>>>
>>>>I disable LOCAL_DEBUG in the production environment, because trying to
>>>>serialize every attribute is probably to expensive under heavy load.
>>>>
>>>>
>>>>@Lintang:
>>>>
>>>>That wouldn't help any. If you put your attributes (which are not
>>>>serializable) into a HashMap (which CAN (!) be serializable) the
>>>>resulting object (map + attribute) still wouldn't be serializable.
>>>>Serializable is more than just implementing the java.io.Serializable
>>>>interface.
>>>>
>>>>
>>>>greetings,
>>>>
>>>>Christoph
>>>>
>>>>
>>>>
>>>>
>>>>Lintang JP wrote:
>>>>
>>>>
>>>>>hi Nishant,
>>>>>You might want to put all your session variable inside HashMap or other
>>>>>datatypes that implements Serializable, rather than put it just in a
>>>>
>>>>single
>>>>
>>>>
>>>>>variable. Refer to the javadocs, what are those Serializable data types
>>>>
>>>>are.
>>>>
>>>>
>>>>>Or maybe you can build your own class with something like this :
>>>>>public class StoredSessionValue implements Serializable {
>>>>>// your session variable goes here
>>>>>// your setter and getter method for those variables goes here
>>>>>}
>>>>>
>>>>>You did right on your <distributable/> tags.
>>>>>On 8/17/05, Nishant Deshpande <nishant.deshpande@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hoping for some help from the tomcat experts on this list.
>>>>>>
>>>>>>I want to ensure all objects stored in sessions are serializable.
>>>>>>
>>>>>>I read that I can put the <distributable/> tag in my web.xml
file to
>>>>>>'enforce' this.
>>>>>>
>>>>>>But I don't see any enforcing happening. I assumed it would throw
>>>>>>exceptions at runtime when I did 'setAttribute("xxx",
>>>>>>SomeNonSerializableObject)'.
>>>>>>
>>>>>>I have put 'distributable' in
>>>>>>
>>>>>>web.xml: <web-app> ... <distributable/> ... </web-app>
>>>>>>
>>>>>>I also have the following in server.xml:
>>>>>>
>>>>>><DefaultContext reloadable="true" allowLinking="true">
>>>>>>
>>>>>><Loader className="org.apache.catalina.loader.DevLoader"
>>>>>>reloadable="true" debug="1"/>
>>>>>><Manager className="org.apache.catalina.session.PersistentManager"
>>>>>>pathname="/cv/data/tmp" debug="5" saveOnRestart="true"
>>>>>>distributable="true">
>>>>>><Store className="org.apache.catalina.session.FileStore"
>>>>>>directory="/cv/data/tmp"
>>>>>>debug="5"/>
>>>>>></Manager>
>>>>>>
>>>>>></DefaultContext>
>>>>>>
>>>>>>
>>>>>>Am I missing something? How is the serializability enforced?
>>>>>>
>>>>>>Also another question: the serialization does not happen in the
>>>>>>directory i specify for Store above, rather it happens in the
>>>>>>$CATALINA_HOME/work/Catalina/* directories. Any ideas about this one?
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Nishant
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message