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 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
