Stateful session bean reference to entity beans passivate?

[Huajun Zhai]

If I have a reference to an entity bean in a stateful session bean, will the reference be valid after re-activation?

[Anthony Watson]

Yes, assuming the entity has not been removed, because stubs are serializeable.

[Keith Rosenfield]

Hi Anthony:

Originally posted by Anthony Watson:
Yes, assuming the entity has not been removed, because stubs are serializeable.

Please explain how does the fact the stubs are serializable ensure the validity of the entity bean reference after activation.
Also, I don't believe that a session bean can have a reference to an entity bean although it can have a reference to its component interface.
Thanks,
[ January 15, 2004: Message edited by: Keith Rosenfield ]
[ January 15, 2004: Message edited by: Keith Rosenfield ]

[Anthony Watson]

Keith, I did a little more digging on the subject. Firstly, ejb people get lazy when talking about ejb and instead of saying "a reference to a bean's EJBOjbect stub", they just say "a reference to a bean." Okay, secondly, some containers use serialization as a means of passivation. So, I was thinking...stubs can be serialized, so they can be deserialized when the EJBOjbect stub is activated. However, in reality, a container does not need to use serialization when passivating a stateful session bean. When you deploy a bean to the container and it implements your interfaces, the container will make the stubs either serializeable or use its own method for storing them off. In any case, when your stateful session bean is activated, the container will use either deserialization or something like it to give you a valid EJBObject stub.
Of course, if the entity was deleted, you'd still be out of luck.

[Kathy Sierra]

Originally posted by Anthony Watson:
...In any case, when your stateful session bean is activated, the container will use either deserialization or something like it to give you a valid EJBObject stub.
Of course, if the entity was deleted, you'd still be out of luck.

Yes, that's how I'd explain it. The spec guarantees that a Container MUST allow any EJB object reference (or EJB home reference) to survive passivation, regardless of how the Container implements that reference. So, if your stateful bean has a reference to another bean's component interface, stored in an instance variable, then the bean does not have to worry about that reference during passivation/activation. That means you do not have to go digging through the vendor's code or other documentation to find out if the *thing* they use for EJBObject references is actually Serializable. It just doesn't matter because it is the Container's job to "take care of it during activation/passivation regardless of whether the reference is to something Serializable, and regardless of whether the Container uses Serialization or something else for passivation..."
Cheers,
Kathy

[Keith Rosenfield]

Hi all:
That does clear some of the confusion, but I still have one area of confusion.
Anthony said:

So, I was thinking...stubs can be serialized, so they can be deserialized when the EJBOjbect stub is activated.

I don't understand why you are talking about stubs being serialized and deserialized. It is my understanding that the bean is what gets serialized. If that bean has a reference to another bean, then the spec guarantees that that reference would get serialized as well. I just don't understand where stubs come into the picture. My understanding of stubs is that they are used in RMI. Why would you want, or need, to serialize them?
I must have popped some confusion pills this morning.
Thanks for your help.

[Anthony Watson]

Keith, I think your confusion about this topic stems from my ambiguity in my previous posts in this thread. When I answered with my "stubs are serializeable" comment, I was making the assumption that the stateful bean had a remote reference to the entity bean. A remote reference IS a stub. In this case, you can't just have a client-local reference to the entity's EJBObject because the real EJBObject is on another machine or VM. The client (the stateful session bean) must have the entity bean's EJBObject stub. So, you call a local method on your stub object, then it serializes the method parameters and passes them across the network to the real EJBObject that resides on another machine or VM. When you want to passivate your stateful session bean, its references to EBJObject stubs must be passivated as well.
However, with local interfaces, there are no stubs. Thus, a local reference is NOT a stub, it's just a plain old reference. It is thus passivated like any other reference that the stateful bean has.
I hope that helps.

[Keith Rosenfield]

Hey Anthony:
Thanks for your clarification. I made the assumption that the entity bean was local to the session bean.
I still am a bit hazy on serialization. What exactly happens when a object reference is serialized? Is just the reference serizalized, or is the object that is being rereferenced serialized? My guess is that the later is true. What happens to the rerefenced object? Does it remain on the heap? If it doesn't, what happens to all other references to that object?
This one deserves a double confused smilie.
Thanks for your help.

[Reid M. Pinchback]

Keith, I think the confusion you had with Anthony's initial response definitely is tied to the serialization issue.
The point of ejbPassivate is to prepare a bean instance for passivation. How do you prepare a bean for passivation? You may sure that it is in a state such that the instance could be serialized and deserialzed correctly.
Strictly speaking I don't think containers aren't required to serialize instances as a way to preserve them, but they are supposed to behave as though that is what happened. The programmer can't be forced to care *how* the container preserved instance state, just to know that whatever is true about the serialiation/deserialization process determines what they (the programmer) can expect of the container.
As to your question 'what happens when an object is serialized?', the typical process is to traverse the object graph and serialize everything. If you want a notational way of thinking about it, for a class defining instances containing a bunch of primitive and object reference fields:
Obj := [ primitive1, ... primitiveN, ref(obj1),... ref(objM) ]
serialized(Obj) := [ serialized(primitive1), ... serialized(objM) ]
That is a bit overly simplistic, because a real serializer has to detect cycles and actually store information about both the reference and the thing it references, but it should get the point across. Serializing an object serializes everything it depends upon. There are some exceptions to that (static fields I think aren't serialized, and transient fields definitely aren't).
So, let's tie this back to the passivation issue. If you could serialize everything in an instance, then to preserve the instance and dump it from memory you could use serialization to write to disk or a database, and use deserialization to restore the instance on demand.
EJB container vendors also get a couple of special-case situations to help them build more performant passivate/activate mechanisms. You could think of it as a special-case refinement to serialization that only applies because the ejb container is the only consumer of the serialized instances. Containers don't *have* to serialize and deserialize ejb object stubs, they just need to restore a viable ejb object stub during activation. Maybe the stub state is too big, and some other book-keeping mechanism is better (e.g. for an entity bean stub you really only need the primary key, while for a stateless session bean stub you really only need to know its home, etc.).
Hope that helps.

[Reid M. Pinchback]

Oops, in the example for entity beans, I should have said you need to know the home and the primary key (and knowing the home could be by handled by saving a HomeHandle, or the container could have some internal book-keeping mechanism of its own).

[Keith Rosenfield]

Hey Reid:
Thanks for you explanation. It has helped clear up things a bit.
I still am not sure what happens to a referenced object when an object is deserialized.
According to your explaination this is a scenario that could occur:
1) Object A has among its members a reference to Object B
2) Object B is also being referenced by Object C
3) Object A is serialized which includes serializing Object B
4) Object B still remains on the heap
5) Object A is deserialized which inludes deserializing Object B
At this point how many Object B's do we have? Does Object A now refernce a different Object B than Object C? Am I not understanding your explanation?
Should I give up java before my head explodes?
Thanks for your help.

[Reid M. Pinchback]

You'll end up with 2 copies of B, unless for some reason the container serialized/deserialized A and C (and B) at the same time.
Since client stubs are only stubs, having two copies causes no problems (there is still only one remote skeleton that they talk to).
Things are pretty sane when you are dealing with EJBObject (i.e. remote) access to beans. All method invocations and returned results are passed by value (because of serialization). There really isn't any way for A and C to share references to the same object (except for things retrieved via identical public JNDI names, which ejbPassivate should ensure are no longer referenced by the bean).
Things can potentially get ugly when you are dealing with EJBLocalObject references. Methods on local references to beans have pass-by-reference semantics. Depending upon pass-by-reference semantics in a component model strikes me as a bit dangerous, and for exactly the issue we are discussing here. If bean A changes the state of a referenced object B, and you expect bean C to see the change, then deserialization during activation can hose you when you end up with two copies of B.

[Keith Rosenfield]

Hey Reid,
I'm not sure where my confusion lies, so I'm not sure what to ask. Please bear with me.
For the moment, let's put aside EJB and just talk about serialization. You said in your last post.

You'll end up with 2 copies of B, unless for some reason the container serialized/deserialized A and C (and B) at the same time.

I'm not sure why you are talking about C being serialized since in my scenario, C is never serialized. Now if you end up with 2 copies of B, couldn't this be a problem. Let's say object B represents a bank account. Couldn't having 2 copies of B possibly result in inconsistencies? Let's say we make a deposit on one copy of B and a withdrawal on another copy of B, wouldn't that leave the bank account that B represents in an inconsistent state? I have a feeling that this scenario would never happen, but I'm not sure.
I appreciate your time and effort in clearing up my confusion.

Thanks.
[ January 19, 2004: Message edited by: Keith Rosenfield ]