Re: persistence with sessions distributable attribute
Christoph - you exactly summarize my situation - i.e. there are
objects with hashmaps and so i really don't know what can be
serialized at the time of serialization.
As regards to 'people', others also work on this webapp, and more
others will work on it in the future... so i want to try to
'futureproof' it somewhat..
thanks - i will probably implement my own PersistanceManager - looks
like the only solution at this stage..
On 8/20/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
Nishant Deshpande wrote:
The SessionListener can check if the attribute implements
Serializable, not if it actually is serializable.
i.e. Nothing to stop people from storing objects which implement
serializable but will barf when actually are serialized.
That is not exactly true.
Look at my example. It tries to write the attribute into a dummy
ObjectOutputstream. If the attribute is not serializable (at that
moment) an exception will be thrown.
This does not save you, of course, from situation where someone puts an
empty HashMap via setAttribute and later puts a not serializable Object
into the map. But doing this (changing an session attribute after the
setAttribute call) isn't recommended anyway, since AFAIK Tomcats session
replication works this way that session are only updated on the remote
nodes if a setAttribute was called.
But another question: you are talking about people putting objects
into the session. Isn't it you - i.e. your webapplication - who is
putting session attributes? You should have enough control over your own
application to ensure that your session attributes are serializable,
shouldn't you?
So - I want to catch each time there is a serialization exception and
log it etc etc.. and even perhaps just drop that object and continue
rather than just drop the serialization for the whole session (this is
what appears to be current behaviour)
Yes, this is apparently the current behaviour. I'm not sure if I like
it, too. I guess it is implemented this way, because if one session
isn't serializable the probability is very high that other sessions are
not serializable, either.
So if you want to change this behaviour, you will probably have to
implement your own PersistanceManager.
On 8/18/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: persistence with sessions distributable attribute
Nishant Deshpande wrote:
The SessionListener can check if the attribute implements
Serializable, not if it actually is serializable.
i.e. Nothing to stop people from storing objects which implement
serializable but will barf when actually are serialized.
That is not exactly true.
Look at my example. It tries to write the attribute into a dummy
ObjectOutputstream. If the attribute is not serializable (at that
moment) an exception will be thrown.
This does not save you, of course, from situation where someone puts an
empty HashMap via setAttribute and later puts a not serializable Object
into the map. But doing this (changing an session attribute after the
setAttribute call) isn't recommended anyway, since AFAIK Tomcats session
replication works this way that session are only updated on the remote
nodes if a setAttribute was called.
But another question: you are talking about people putting objects
into the session. Isn't it you - i.e. your webapplication - who is
putting session attributes? You should have enough control over your own
application to ensure that your session attributes are serializable,
shouldn't you?
So - I want to catch each time there is a serialization exception and
log it etc etc.. and even perhaps just drop that object and continue
rather than just drop the serialization for the whole session (this is
what appears to be current behaviour)
Yes, this is apparently the current behaviour. I'm not sure if I like
it, too. I guess it is implemented this way, because if one session
isn't serializable the probability is very high that other sessions are
not serializable, either.
So if you want to change this behaviour, you will probably have to
implement your own PersistanceManager.
On 8/18/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: persistence with sessions distributable attribute
The SessionListener can check if the attribute implements
Serializable, not if it actually is serializable.
i.e. Nothing to stop people from storing objects which implement
serializable but will barf when actually are serialized.
So - I want to catch each time there is a serialization exception and
log it etc etc.. and even perhaps just drop that object and continue
rather than just drop the serialization for the whole session (this is
what appears to be current behaviour)
i'm talking about 2 possibly orthogonal things here.. but just laying
out what i'm trying to do.
On 8/18/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: persistence with sessions distributable attribute
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Re: persistence with sessions distributable attribute
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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:
Re: persistence with sessions distributable attribute
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: persistence with sessions distributable attribute
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
---
http://www.psychotazkia.or.id
Re: persistence with sessions distributable attribute
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [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: persistence with sessions distributable attribute
Apologies - I omitted the tomcat version: 5.0.28 On 8/16/05, Nishant Deshpande [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: persistence with sessions distributable attribute
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
---
http://www.psychotazkia.or.id
