This week's book giveaway is in the OCP forum.
We're giving away four copies of OCP Oracle Certified Professional Java SE 11 Developer Practice Tests and have Scott Selikoff and Jeanne Boyarsky on-line!
See this thread for details.
Win a copy of OCP Oracle Certified Professional Java SE 11 Developer Practice Tests this week in the OCP forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Ron McLeod
  • Tim Cooke
Sheriffs:
  • Devaka Cooray
  • paul wheaton
  • Mark Herschberg
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
  • Jj Roberts
Bartenders:
  • Carey Brown
  • salvin francis
  • Piet Souris

Using ejbPassivate() to garbage collect Entity Bean attribute objects

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe I've misunderstood the spirit behind the ejbPassivate() and ejbActivate() mechanism but I thought these were primarily for the storage of stateful session bean state when the bean is moved out of memory and into temporary persistent storage. I thought the idea was that non serializable bean attributes, such as remote connections, could be nulled on passivate and recreated on activate.

However, at my current shop they always "null out" entity bean attributes in ejbPassivate() to make garbage collection more efficient, i.e. the objects that are/were attributes can be passivated even though the bean is still pooled. I don't think this is the intended use of ejbPassivate() but the idea seems a very plausible one to my simple mind. However, I rather imagine the intention is that we should use instance pool size and cache size configurations to manage memory utilization rather than through the ejbPassivate() callback method.

Unfortunately, I have a nagging concern. I vaguely remember reading once (I cannot find it now ... grrrr) that when using our app server (JBoss) entity beans returned to their instance pool get pulled out of the queue and reused if they have the same unique key as a new client is now requesting. So, it worries me that having null attributes could potentially cause problems in this scenario. Does this make any sense?

Fyi we are using,
JBoss 3.2.5
commit-option B
J2SE 1.4.2_02
BMP

Thanks in advance for your wise words.
Keith Thomas
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would think that after calling ejbActivate, a container would next need to call ejbLoad before any business methods could be used. I think the spec only says that the container should call ejbLoad whenever it needs to in order to synchronize with the database. JBoss shouldn't rely on a bean in the pool being in the proper synchonization state.
 
Ranch Hand
Posts: 8943
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

entity beans returned to their instance pool get pulled out of the queue and reused if they have the same unique key as a new client is now requesting.



No it is not true. When the bean is pulled out of the pool ejbActivate method gets called and then ejbLoad method.
 
BWA HA HA HA HA HA HA! Tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic