Comments on: Why does javax.ejb.EnterpriseBean extends java.io.Serializable?

By: M.Alfred Mathavan

M.Alfred Mathavan — Mon, 27 Oct 2003 07:03:16 +0000

The data Storage may be in a different computer and the EJB Enterprise Tier may be in a different computer so during passivation and activation the data need to travell via network to the EIS tier hence the object should be serialized.

By: Matt Quail

Matt Quail — Sat, 29 Mar 2003 11:46:37 +0000

OJB put me on to this non-answer from a year ago:

http://www.mail-archive.com/ejb-interest@java.sun.com/msg21279.html

By: Oliver Burn

Oliver Burn — Thu, 27 Mar 2003 08:38:42 +0000

The EJB spec talks a lot about the life-cycle of an EJB. It does not talk about when an EJB is serialized. Therefore you can make no assumptions about when an EJB is serialized and de-serialized. If you need to store attributes then in an MDB or SLSB you would need to do this yourself.

I personally think there is no obvious answer. It probably goes back to early EJB 1.0 days, and now they do not want to remove the interface and break a (mythical) contract.

By: bjd

bjd — Thu, 27 Mar 2003 04:39:55 +0000

Even though you do not normally store the attributes of stateless Session EJBs and
MDBs, you might want the ability to do so, therefore you must have java.io.Serializable in place.

By: Matt Quail

Matt Quail — Wed, 26 Mar 2003 22:28:58 +0000

Thomas, I agree that bean remote interfaces definitely need to be serializable; it is required because they are Remote; eg so that they can be passed-as-arguments/returned-as-valued to/from remote methods.

But EnterpriseBean is not for the remote interface, its for the bean implementation classes. Instances of those DO NOT get passed around from remote methods; those instances remain "nice and snug" inside the EJB container. That is, EJB impls do not get marshalled during remote calls, just their remote interfaces.

Stateless SB's implementation instances don't get marshalled during calls either... but they may get serialized during activation/passivation.

So, once again, I'm left wondering why an Entity EJB is serializable... is the bean implementer required to think about if their class is properly serializable? Will an Entity EJB be passivated before a container "serializes" it... or will an Entity EJB NEVER be serialized by the container...?

By: Thomas Roka-Aardal

Thomas Roka-Aardal — Wed, 26 Mar 2003 12:01:31 +0000

I meant to say "how do you send a bean interface if it isn't serializable"...

By: Thomas Roka-Aardal

Thomas Roka-Aardal — Wed, 26 Mar 2003 12:00:29 +0000

Isn’t this due to the fact that also stateless session beans are remote by spec? I mean, how do you send a bean (rmi) if it isn’t serializable? You wouldn’t be able to guarantee the marshalling/unmarshalling of your objects.

By: bjd

bjd — Wed, 26 Mar 2003 09:00:43 +0000

It's my understanding that it's done this way so that EJBs are clusterable across multiple app servers. That way you can have two beans which have a 1-to-many relationship and yet still have the bean clusterable.

eg: class fooBean implements EntityBean { abstract Collection barBean(); ... }

fooBean contains a Collection of barBean, which is not serializable. The javax.ejb.EnterpriseBean extends Serializable so that the bean is serializable and thus clusterable.

I think.

By: Oliver Burn

Oliver Burn — Wed, 26 Mar 2003 04:10:50 +0000

Great post – be interested to see if somebody posts the reason why. Other than SUN were lazy.