• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Session bean instance variables ready for passivation

 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, guys!
On page 203 of HFEJB book, you can see that "bean's local component or home interface" are an example of "passivatable" instance variable. That is, it can be either an entity local component interface or a session local component interface.
Unfortunatelly , on page 71 of the spec, you find out that only "entity's local component or home interface" can be serialized.
So according to the spec, isn't a requirement to serialize the references to session local interfaces (component and home)? That's exactly what HFEJB is pointing!
Thanks in advance.
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Fernando,

Passivation is used on entity and stateful beans. http://java.sun.com/developer/onlineTraining/EJBIntro/EJBIntro.html explains it well.

entity beans

The ejbPassivate() and ejbActivate() methods are invoked on the bean by the container just before the bean is passivated and just after the bean is activated, respectively. Passivation in entity beans means that the bean instance is disassociated with its remote reference so that the container can evict it from memory or reuse it. It's a resource conservation measure the container employs to reduce the number of instances in memory. A bean might be passivated if it hasn't been used for a while or as a normal operation performed by the container to maximize reuse of resources. Some containers will remove beans from memory, while others will reuse instances for other more active remote references. The ejbPassivate() and ejbActivate() methods provide the bean with a notification when it is about to be passivated (disassociated with the remote reference) or activated (associated with a remote reference).



stateful beans

To conserve resources, stateful session beans may be passivated when they are not in use by the client. Passivation in stateful session beans is different than for entity beans. In stateful beans, passivation means the bean's conversational-state is written to a secondary storage (often disk) and the instance is removed from memory. The client's reference to the bean is not affected by passivation, it remains alive and usable while the bean is passivated. When the client invokes a method on a bean that is passivated, the container will activate the bean by instantiating a new instance and populating its conversational-state with the state written to secondary storage. This passivation/activation process is often accomplished using simple Java serialization but it can be implemented in other proprietary ways as long as the mechanism behaves the same as normal serialization. (One exception to this is that transient fields do not need to be set to their default initial values when a bean is activated.)



So, all the passivation and activation processes are done just on the beans and not on the local/remote/home interfaces.

-- Dan
 
Fernando Matias Valadao
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Dan
Thank you very much for your reply.
I understood your consideration, but what I was arguing about was the instance variables of the bean that is about to be passivated/activated, not the bean itself.
I was asking about the differences between HFEJB and the spec (or maybe there was no difference and I was just
Again: In HFEJB it's written that "bean's local component or home interface are an example of "passivatable" instance variable", while in the spec we can read that "entity's local component or home interface can be serialized".
Hope it became clearer now.
Thanks.

Fernando
 
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Even I am looking for the answer to this question.

I have copied the statments from spec here -

'The objects that are assigned to the instance�s non-transient fields after the ejbPassivate method completes must be one of the following:

� An "enterprise bean�s" remote interface reference, even if the stub class is not serializable.
� An "enterprise bean�s" remote home interface reference, even if the stub class is not serializable.
� An "entity bean�s" local interface reference, even if it is not serializable.
� An "entity bean�s" local home interface reference, even if it is not serializable.

Why the diff between the first two and the last two?

Regards,
Leena
 
Fernando Matias Valadao
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Kathy / Valentin / Bert:
Don't you have any tips to solve our question?
Thanks in advance

Fernando
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic