Serialization vs. Synchronization and web application

[Tung Chau]

Hi,
I know this is a silly question, but I am so confused. When should I
make my Java class implement Serializable? I understand the basic idea
of Serialization and Synchronization. However, I don't know when I
should use them. In a web application which does not use EJB, should I
make my class Synchronized or Serialized? Would that slow down the
software? Is that necessary though? I thought that the synchronization
and concurrency are taken care in the DBMS already, unless we want to
build a distributed software.
Please help me clear this up.
Thanks alot.
Hongvan Nguyen

 

[Tov Are Jacobsen]

Den Fri, 06 Aug 2004 14:42:48 -0700, skrev Tung Chau:

Hi,
I know this is a silly question, but I am so confused. When should I
make my Java class implement Serializable? I understand the basic idea
of Serialization and Synchronization. However, I don't know when I
should use them. In a web application which does not use EJB, should I
make my class Synchronized or Serialized? Would that slow down the
software? Is that necessary though? I thought that the synchronization
and concurrency are taken care in the DBMS already, unless we want to
build a distributed software.
Please help me clear this up.

Synchronization is a feature for controlling multithreaded access to
methods and variables.

You mostly need to worry about concurrency within your own application.

Serialization is a feature for converting objects to a stream of bit's so
you can store them.

cheers,

 

[Oscar kind]

I know this is a silly question, but I am so confused. When should I
make my Java class implement Serializable? I understand the basic idea
of Serialization and Synchronization. However, I don't know when I
should use them.

Synchronization is used to make sure concurrent access to a resource from
different threads will go right. You'll need it to make sure the state of
an object remains valid. Sometimes you don't need it because (for example)
you don't use threads directly or via Swing, only one thread may write
single values or your servlets have no state and use the session of the
user to store a state in.

Serialization is needed to send objects over a byte stream. When you need
it and are not using RMI, you'll know. When using RMI, all method
parameters and return types of the remote methods must be serializable.

 

[John C. Bollinger]

Serialization is needed to send objects over a byte stream. When you need
it and are not using RMI, you'll know.

Usually. You will sometimes find that somebody tries to serialize your
objects when you didn't expect it. An excellent example in the OP's
context would be attributes of an HttpSession: some servlet containers
will serialize sessions under certain circumstances, and if they contain
non-Serializable attributes then that mucks up the works. The nature of
the problem often is not immediately obvious, especially when, as may be
the case, the only message you see is the container complaining about
not being able to _de_serialize the session at some later time.

Generally, though, I would say to not implement Serializable unless you
have to.


John Bollinger
(e-mail address removed)