session bean, session bean instance and session object!!!
Brian Smith
Ranch Hand
Posts: 232
Kathy Sierra
Cowgirl and Author
Rancher
Rancher
Posts: 1589
5
posted 13 years ago
Usually, these three mean the same thing. Although sometimes when people use the word "bean", it means the entire component. In other words, if I say, "The ShoppingCart bean", I may mean the bean PLUS its interfaces.
Now, with entity beans, there IS a difference, although it is not always clear. The biggest issue is when someone says (including the spec), "An entity bean survives a server crash." Clearly, there is NO way that an object can survive the crash. So the entity *instance* dies, but the entity bean is considered "alive" simply because the entity is STILL in the underlying persistent store AND the bean type is still deployed. In other words, an entity bean is said to exist EVEN WHEN NO ENTITY OBJECT/INSTANCE IS CURRENTLY REPRESENTING THAT ENTITY. If it is *possible* for an entity bean to come out of the pool and BE that particular entity, then the entity bean is said to exist. So an entity BEAN can exist even if an entity instance does not yet exist in the pool, as long as the container is able to create a bean instance and then populate it with that particular entity's data.
Usually the term instance and object are used to mean the same thing... an instance/object on the HEAP. The term "bean" does not always imply an instance/object on the heap, although with session beans, the spec does use those terms interchangeably, and there is no difference really in talking about a bean vs. an instance, unless you are referring to the bean as the component. "I made a session bean" or "I deployed a session bean" means I deployed a component of that type into the server, but that does not mean the same thing as an instance and object.
Really, the only time I think these terms matter is with entity beans. Where you must know, for example, that when an ENTITY BEAN dies (through an ejbRemove()), the entity INSTANCE does NOT die, but instead goes back to the pool as a still living, breathing, on-the-heap object. An entity bean INSTANCE does not die until the server calls unsetEntityContext(), or the bean throws a system exception, or the server crashes.
I probably just made it more confusing
cheers,
Kathy
Now, with entity beans, there IS a difference, although it is not always clear. The biggest issue is when someone says (including the spec), "An entity bean survives a server crash." Clearly, there is NO way that an object can survive the crash. So the entity *instance* dies, but the entity bean is considered "alive" simply because the entity is STILL in the underlying persistent store AND the bean type is still deployed. In other words, an entity bean is said to exist EVEN WHEN NO ENTITY OBJECT/INSTANCE IS CURRENTLY REPRESENTING THAT ENTITY. If it is *possible* for an entity bean to come out of the pool and BE that particular entity, then the entity bean is said to exist. So an entity BEAN can exist even if an entity instance does not yet exist in the pool, as long as the container is able to create a bean instance and then populate it with that particular entity's data.
Usually the term instance and object are used to mean the same thing... an instance/object on the HEAP. The term "bean" does not always imply an instance/object on the heap, although with session beans, the spec does use those terms interchangeably, and there is no difference really in talking about a bean vs. an instance, unless you are referring to the bean as the component. "I made a session bean" or "I deployed a session bean" means I deployed a component of that type into the server, but that does not mean the same thing as an instance and object.
Really, the only time I think these terms matter is with entity beans. Where you must know, for example, that when an ENTITY BEAN dies (through an ejbRemove()), the entity INSTANCE does NOT die, but instead goes back to the pool as a still living, breathing, on-the-heap object. An entity bean INSTANCE does not die until the server calls unsetEntityContext(), or the bean throws a system exception, or the server crashes.
I probably just made it more confusing
cheers,
Kathy
Brian Smith
Ranch Hand
Posts: 232
posted 13 years ago
Thanks for the respons, Kathy.
But i still need to make it clear here. Let's look at the following line from the Spec, page 55 under the Overview in the 2nd paragraph where it says, A Client accesses a SESSION OBJECT through the SESSION BEAN's component interface.
Do the *session object* and *session bean* mentioned above mean SAME thing?
Are those term refering to *AdviceBean* in the case of HF EJB example?
if i say session bean instance, does this refer to the *AdviceBean* class?
could you please make it clear to me? I don't know what is my source of confusion!
thanks.
[ December 23, 2003: Message edited by: Namaste Sathi ]
But i still need to make it clear here. Let's look at the following line from the Spec, page 55 under the Overview in the 2nd paragraph where it says, A Client accesses a SESSION OBJECT through the SESSION BEAN's component interface.
Do the *session object* and *session bean* mentioned above mean SAME thing?
Are those term refering to *AdviceBean* in the case of HF EJB example?
if i say session bean instance, does this refer to the *AdviceBean* class?
could you please make it clear to me? I don't know what is my source of confusion!
thanks.
[ December 23, 2003: Message edited by: Namaste Sathi ]
|