Comments on: Why does javax.ejb.EnterpriseBean extends java.io.Serializable? http://madbean.com/2003/mb2003-13/ Your zero step program Sat, 22 Nov 2008 07:13:00 +0000 http://wordpress.org/?v=2.6.3 By: M.Alfred Mathavan http://madbean.com/2003/mb2003-13/#comment-22 M.Alfred Mathavan Mon, 27 Oct 2003 07:03:16 +0000 http://madbean.com/blog/2003-13#comment-22 <p>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.</p> 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 http://madbean.com/2003/mb2003-13/#comment-21 Matt Quail Sat, 29 Mar 2003 11:46:37 +0000 http://madbean.com/blog/2003-13#comment-21 <p>OJB put me on to this non-answer from a year ago:</p> <p>http://www.mail-archive.com/ejb-interest@java.sun.com/msg21279.html</p> 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 http://madbean.com/2003/mb2003-13/#comment-20 Oliver Burn Thu, 27 Mar 2003 08:38:42 +0000 http://madbean.com/blog/2003-13#comment-20 <p>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.</p> <p>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.</p> 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 http://madbean.com/2003/mb2003-13/#comment-19 bjd Thu, 27 Mar 2003 04:39:55 +0000 http://madbean.com/blog/2003-13#comment-19 <p>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.</p> 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 http://madbean.com/2003/mb2003-13/#comment-18 Matt Quail Wed, 26 Mar 2003 22:28:58 +0000 http://madbean.com/blog/2003-13#comment-18 <p>Thomas, I agree that bean <em>remote interfaces</em> 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.</p> <p>But EnterpriseBean is not for the <em>remote interface</em>, its for the <em>bean implementation</em> 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.</p> <p>Stateless SB's implementation instances don't get marshalled during calls either... but they <em>may</em> get serialized during activation/passivation.</p> <p>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 <em>NEVER</em> be serialized by the container...?</p> 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 http://madbean.com/2003/mb2003-13/#comment-17 Thomas Roka-Aardal Wed, 26 Mar 2003 12:01:31 +0000 http://madbean.com/blog/2003-13#comment-17 <p>I meant to say "how do you send a bean <em>interface</em> if it isn't serializable"...</p> I meant to say "how do you send a bean interface if it isn’t serializable"…

]]> By: Thomas Roka-Aardal http://madbean.com/2003/mb2003-13/#comment-16 Thomas Roka-Aardal Wed, 26 Mar 2003 12:00:29 +0000 http://madbean.com/blog/2003-13#comment-16 <p>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.</p> 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 http://madbean.com/2003/mb2003-13/#comment-15 bjd Wed, 26 Mar 2003 09:00:43 +0000 http://madbean.com/blog/2003-13#comment-15 <p>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.</p> <p>eg: class fooBean implements EntityBean { abstract Collection barBean(); ... }</p> <p>fooBean contains a Collection of barBean, which is not serializable. The javax.ejb.EnterpriseBean extends Serializable so that the bean <em>is</em> serializable and thus clusterable.</p> <p>I think.</p> 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 http://madbean.com/2003/mb2003-13/#comment-14 Oliver Burn Wed, 26 Mar 2003 04:10:50 +0000 http://madbean.com/blog/2003-13#comment-14 <p>Great post - be interested to see if somebody posts the reason why. Other than SUN were lazy. ;-)</p> Great post - be interested to see if somebody posts the reason why. Other than SUN were lazy. ;-)

]]>