Entity Bean Instance Life Cycle

[Santosh Ramachandrula]

Reference: EJB 2.0 Spec
page: 169
1. The container can choose to passivate an entity bean instance with in a transaction
Why is this allowed on Entity Beans and not on Session Beans.
2. Can't we do a ejbFind<method>(args) on a bean instance that is in READY state? . (IF not why??)

[Weerawit Maneepongsawat]

1. The container can choose to passivate an entity bean instance with in a transaction

because It's CMT, every method on CMT transaction will finish at the method end.

2. Can't we do a ejbFind<method>(args) on a bean instance that is in READY state? . (IF not why??)

ejbFind not same as ejbSelect because ejbFind invoke from Home Interface only, From container point of view if client invoke ejbFind method on Home may not have EJBObject in method ready state. but ejbSelect like a private method, that mean it's can be invoke on method ready state.

Hope this can help you.

[Santosh Ramachandrula]

1. I don't think I quite understood the response for the first question

because It's CMT, every method on CMT transaction will finish at the method end.

If the container is done executing the method in transaction then it is not in transaction any more and hence can be passivated but the quote from EJB Spec does'nt say that The container can choose to passivate an entity bean instance with in a transaction

[Roger Chung-Wee]

I am sure that this is bound up with ejbStore(). After invoking this method, the Container may decide that it no longer needs the entity bean instance, so passivates the bean. If an instance is later required in the transaction, the Container can always activate another instance from the pool.
The commit, of course, will only take place at the end of the transaction and is not dependent on any invocation(s) of ejbStore().

[Vishwa Kumba]

Originally posted by Santosh Ram:
1. The container can choose to passivate an entity bean instance with in a transaction. Why is this allowed on Entity Beans and not on Session Beans?

The concept of passivation is different for Session beans and Entity beans. Passivation/Activation of a Session bean is related to the serialization/deserialization of Session beans state data while the passivation/activation for Entity beans means swapping the beans in and out of the pool.Both are for the same purpose - preservation of resources.
If the container did not passivate entity beans in prolonged transactions, then this could easily lead to scalability issues, both at the Container and the database level.

2. Can't we do a ejbFind<method>(args) on a bean instance that is in READY state?. IF not why?

No. The Container always executes finder methods in beans that are in a pooled state. Finder methods are more like global methods. Entity beans in the Ready state are different from each other while the entity beans in the pooled state have no unique identity and all beans of the same type are the same. So any bean could be picked up by the Container to execute your finder method.

[Santosh Ramachandrula]

Vishwa Thanks for the answer, your answer has raised few more questions to me.....
My Question
1. The container can choose to passivate an entity bean instance with in a transaction. Why is this allowed on Entity Beans and not on Session Beans?

Vishwa's Response
The concept of passivation is different for Session beans and Entity beans. Passivation/Activation of a Session bean is related to the serialization/deserialization of Session beans state data while the passivation/activation for Entity beans means swapping the beans in and out of the pool.Both are for the same purpose - preservation of resources.
My response to the above answer

How does this make difference by not allowing a session bean to passivate data that is transaction and allowing an entity bean to passivate is in transaction?

----------------------------------------------------------------------------

----------------------------------------------------------------------------
My Question
2. Can't we do a ejbFind<method>(args) on a bean instance that is in READY state?. IF not why?

Vishwa's Response

No. The Container always executes finder methods in beans that are in a pooled state. Finder methods are more like global methods. Entity beans in the Ready state are different from each other while the entity beans in the pooled state have no unique identity and all beans of the same type are the same. So any bean could be picked up by the Container to execute your finder method.
My response to the above answer

Why is this not applicable to ejbSelect<method>(args)

----------------------------------------------------------------------------

[Roger Chung-Wee]

How does this make difference by not allowing a session bean to passivate data that is transaction and allowing an entity bean to passivate is in transaction?

Because passivation is only done in an unspecified transaction context. See my last post for an explanation.