Win a copy of Getting started with Java on the Raspberry Pi this week in the Raspberry Pi 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Liutauras Vilda
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Piet Souris

Some questions

 
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi friends
Got a couple of questions bothering me.
1. Whats the result of invoking the remove() method on passivated stateful session bean ? Will ejbRemove() be called ?
2. If remove() method is invoked on an entity bean in the pooled state, will ejbActivate() and ejbLoad() be invoked on it, before calling the ejbRemove() method ?
Thanks a lot
Vipin
[ December 20, 2003: Message edited by: Vipin Mohan ]
 
Saloon Keeper
Posts: 3848
42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi, Vipin
1. There is nothing in spec about removing from passivated state except as a timeout. Also, cpec clearly says that SFSB will be activated before any method call in passiveated state. So, my guess is:
a) bean will be activated
b) ejbRemove will be called
2. Sure, I think, the bean (will not say which one exactly - all of them are equal) will be :
a) activated - ejbActivate
b) loaded - ejbLoad
c) removed - ejbRemove
then bean will return to the pool.
p.s. I may be wrong
 
Vipin Mohan
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you are right.
Thanks for the explanations, Mikalai.
Vipin
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi guys,
adding on to your discussions,
I doubt about that the container will bother to actiavate() a bean again if it is already passivated.
If we look from the containers point of view then it's like this...
The bean is passivated... the container is wating for timeout to pass so that it can remove the bean.
Now the client calls ejbRemove(), now as the bean is already passivated, the container can safely assume that as a developer we have taken care of the state of the bean in the respective methods, therefore eventhough there is nothing in the discussion regarding the passivated session bean getting a remove() call, the container will never call its ejbActivate(), ejbLoad() and then call ejbRemove().
To justify my answer just think of yourself....
There is law you have to abide by... which says go to your home after school. It doesnot specify which way you choose to go. Being a guy to follow the rules and knowing that there is no rule on way to follow would you take the longest way to go back to home or the shortest way.
The obvious answer is the shortest way.
To activate() and load() a bean is a heavy task for any container, so the container will never say "ok i will reactivate() and reload() the bean just to delete it again...
sudeep
 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the case of a cascade delete the entity bean has to be activated and loaded before it is removed. In this case the bean has to get the correct state for the beans that is in a relationship with the bean so they can be deleted as well.
/Magnus
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vipin Mohan:

1. Whats the result of invoking the remove() method on passivated stateful session bean ? Will ejbRemove() be called ?


I also tend to agree with Sudeep, for Stateful session beans.
I think most of the times, the code that goes into ejbPassivate() also goes into ejbRemove(), so this piece of code might not get executed when the bean times out in a passivated state, b'cos the code would already been executed once in the ejbPassivate() method just before passivation.
HF EJB book-p:211, Lifecycle overview - SFSB - "Bean times out while passivated" - also says that the container does not call ejbRemove() method when it decides to remove the bean.
 
Vipin Mohan
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi folks
Now I'm really confused. That argument sounds reasonable too.
Can Kathy or Bert please give us the answer to this ?
Thanks
Vipin
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy -- for stateFUL session beans, the container will treat a remove() method as a business method, and "wake up" the bean to invoke the ejbRemove() method (so ejbActivate() will be called first).
When a bean times out while passivated, the container does NOT "wake up" the bean, because it knows that the relationship between this bean and this client is already OVER, as far as the container is concerned, so there is nothing else to be done.
But the container treats a remove() call as something active from the client -- something that means the client/bean relationship is still alive and well, even if the remove() means "Hey bean, I'm done with you now... so complete my conversation with you... finish my session." and the bean may do something *related to that client*.
So the big question is about WHERE do you do your cleanup, and you still must assume that ejbRemove() might not be called (because of all the other issues -- server crash, timeout while passivated, system exception) so, here would be my advice:
* Do NOT rely on ejbRemove() for your clean up.
* Do NOT assume ejbRemove() will be called.
* Use ejbRemove() for extra client-session-specific things that you want to do as a result of KNOWING that the client has actively said he is done talking to you. But do not put crucial clean-up code in here.
So, when is ejbRemove() called on a session bean?
1) When the container *chooses* to remove a stateLESS bean.
2) When the client calls remove() on a stateFUL bean, and the bean is either passivated or active.
When is ejbRemove() NOT called?
1) When the bean (any type) throws a system exception.
2) When the container crashes
3) When a stateFUL bean times out while passivated.
Now, just one little clarification... a few of you have mentioned ejbLoad(), but remember... there is NO ejbLoad() for session beans
Only entity beans are activated and loaded. StateFUL beans are simply activated, and then the business method (or in this case, the ejbRemove()) is called.
cheers,
Kathy
"One test to rule them all. One test assigned them. One test to bring them all and in Prometric grind them."
 
Ranch Hand
Posts: 418
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kathy Sierra:
When is ejbRemove() NOT called?
1) When the bean (any type) throws a system exception.
2) When the container crashes
3) When a stateFUL bean times out while passivated.


Suppose the ejbRemove() method in the SF session bean contains some cleanup code, which is assumed to be executed , when the bean is removed (or destroyed ). So what happens in case of pt# 3? in the passivated state, if the bean is removed due to time out and ejbRemove() is not called by the container, when does the cleaup excute? rather where shd this cleanup code be written to make sure that it is always executed when the bean is removed?

Is ejbRemove() still a safe place to do cleanup, if the container does not guarantee that ejbRemovbe() is always executed??? (referring to pt#3)
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rashmi Tambe:
Is ejbRemove() still a safe place to do cleanup, if the container does not guarantee that ejbRemovee() is always executed??? (referring to pt#3)


Rashmi,
In the above Kathy's post, it is mentioned that ejbRemove() is not always a reliable method...
Read the foll. post also....HTH!
https://coderanch.com/t/158460/java-EJB-SCBCD/certification/where-put-critical-cleanup-things
 
There are 10 kinds of people in this world. Those that understand binary get this tiny ad:
Low Tech Laboratory
https://www.kickstarter.com/projects/paulwheaton/low-tech-0
reply
    Bookmark Topic Watch Topic
  • New Topic