• 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 ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

timeout in stateful session bean

Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Buddies,

I read that the stateful session bean in "method ready" will go to "does not exist" state by ejbRemove() or time out. I have a question here.
The waiting-time of time-out should be longer than passivation, right? Then, when it comes to the time-out, why doesn't it go into "passivated state" first?

Thanks a lot.
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not necessary for a stateful session bean to go to passivated state always. The container may never call ejbPassivate if it feels that the existing session beans in the pool are sufficient to handle the client requests.The container may call ejbPassivate if a request comes and it sees that all other beans are busy serving clients, and this bean is sitting idle for some time.In this case Container may think like lets passivate this bean and serve the current request using this bean.

Ranch Hand
Posts: 563
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you raised a good question. Well, here is your answer, it tells you why the bean is simply removed when it times out, and not just passivated. Also, that is explained in HFE.

When the stateful session bean times out (due to user inactivity), the bean still stays alive in the stateful cache on the server. The price for this abandoned bean is:
Server memory is not used efficiently - the abandoned bean stays in memory until it is passivated. As the client that created the bean no longer exists, the bean occupies memory unnecessarily. If your stateful EJB is clustered, not calling remove keeps the bean in the cache of the primary server and its replicated counterpart on the secondary server. In addition to the beans, the replication machinery on both the servers also occupies memory.
Performance drops - the abandoned bean will be removed from the memory by passivating it to the disk. This affects performance as passivation is an expensive operation that involves serializing the bean to the disk.
I hired a bunch of ninjas. The fridge is empty, but I can't find them to tell them the mission.
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic