Forums Register Login

ejbRemove for a session bean

+Pie Number of slices to send: Send
The EJB2.0 Specs mentions that "A timeout of client inactivity while the instance is in the passive state will result in the ejbRemove() method not being called". So what if the bean times out while it is in the method ready state ? Will ejbRemove() method be called then ? Is this mentioned in the specs any where ?
Thank you
Deepti
+Pie Number of slices to send: Send
In such a case the conatiner may call the ejbPassivate() method on the bean.
+Pie Number of slices to send: Send
In EJB Spec2.0 See 7.6 Stateful Session bean state Diagram

I will it help you.
+Pie Number of slices to send: Send
 

Originally posted by Deepti Sabarinath:
The EJB2.0 Specs mentions that "A timeout of client inactivity while the instance is in the passive state will result in the ejbRemove() method not being called". So what if the bean times out while it is in the method ready state ? Will ejbRemove() method be called then ? Is this mentioned in the specs any where ?
Thank you
Deepti


Howdy
[yes, I'm once again alive and online after a loooong break finishing the book]
If the bean times out while method-ready, yes, the Container calls ejbRemove() to give the bean a chance, just as if the client had invoked remove() on the bean's component interface (or remove(handle) on the bean's remote home interface).
It's in the spec... don't have it in front of me to give you the actual page, but if you look in the session bean chapter, you'll find the lifecycle diagrams, and they show that you can have several paths to the "does not exist" state:
1) Client calls remove() on a stateful bean that's in the method-ready state, OR the bean times out while in the method-ready state, in which case Container calls ejbRemove() and then kills the bean
2) Client calls remove() on a stateful bean that's been passivated, OR the bean times out while passivated, in which case Container does NOT call ejbRemove(), but simply kills the bean
3) Bean throws a system exception (which for the bean, means any runtime exception including an EJBException) in which case, the Container logs the exception and kills the bean WITHOUT calling ejbRemove().
The exam indeed expects you to know the following ways in which a bean could MISS getting ejbRemove():
1) Container crashes
2) Bean times out while passivated
3) Bean throws a system exception
Hope that helps
p.s. The book has started to ship! I just got a copy from the publisher, so I've now held it in my hands. Amazon customers will be getting it first, and O'Reilly thinks that the Amazon pre-orders will go out within the next several days. It will not appear in stores for another week or two. The books are in the process of moving through warehouses and distribution channels.
Whew! Now I can finally go back to having fun and hanging out at the ranch.
cheers,
Kathy
I like you because you always keep good, crunchy cereal in your pantry. This tiny ad agrees:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 711 times.
Similar Threads
ejbRemove
ejbRemove In Session Bean
releasing resources
T or F?
EJB Life Cycle
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 04:18:27.