• Post Reply Bookmark Topic Watch Topic
  • New Topic

Timeout of passivated sessions

 
Nathaniel Stoddard
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I couldn't figure this out by reading the spec. What happens when a session is passivated by the server (for memory usage for example), and later is invalidated by the session-timeout configured in the web.xml? Will the session be activiated and then the sessionDestroyed method of HttpSessionListener called, or will the session just quietly be killed?

EJBs are quietly destroyed when passivated, so I thought it might be the same with HttpSessions, but I couldn't find anything conclusive. Anybody have an insight into this?
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the session is activated before killing.The reason is HTTPSessionListner. As there is nothing like listners in EJB so they might not be calling the ejbRemove while killing a session which is passivated.

Its just a guess.
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nathaniel Stoddard:

EJBs are quietly destroyed when passivated.

In what scenarios will this happen? When will passivated ejbs be destroyed?

Originally posted by Rahul Bhattacharjee:
I think the session is activated before killing.The reason is HTTPSessionListner. As there is nothing like listners in EJB so they might not be calling the ejbRemove while killing a session which is passivated.

Its just a guess.


Ejb has callback methods for passivation and activation. That are nothing but listeners for containers actions.
 
Nathaniel Stoddard
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rahul,

Thanks for the reply. I hadn't thought about it that way. I suppose the web container could remember whether there was any HttpSessionListeners so it could just delete the passivated HttpSession immediately (from a database for example), if possible. It probably wouldn't want to go to all the trouble of activating every single passivated HttpSession just so it could finalize it without any listeners being called.

It's a bummer the servlet spec doesn't have those nice lifecycle charts for a HttpSession like the EJB spec has for all its beans.
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nitesh Kant:


Ejb has callback methods for passivation and activation. That are nothing but listeners for containers actions.


During runtime exception the ejbRemove is not called , even during server crash the ejbRemove is not called and off course during timeout in passivated state, the ejbRemove is not called.
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My bad, i missed out the timeout for stateful session beans. Been sometime since i worked on EJBs, but thought i still had some connect. Sadly, i was wrong

Originally posted by Rahul Bhattacharjee:


During runtime exception the ejbRemove is not called , even during server crash the ejbRemove is not called and off course during timeout in passivated state, the ejbRemove is not called.


Yeah, these things are clearly mentioned in the specs.
I think in case of a runtime exception, since the bean is in an unusable state, it doesnt make sense to call ejbRemove.
In case of a server crash, only god can save the bean
In case of passivated bean, i think it is acceptable, since before passivation, ejbPassivate would have been called and any resources used by the bean should have been released.
I think here lies the difference between http session passivation and ejb passivation. Since, there is a callback on passivation of bean by the container and not so in the case of http session, so i think it will be ruthless to simply remove the session without even informing the listener. Atleast the application should have some info about when the session is removed if not when passivated.
Also, passivation not being a formal contract between the container and the application, so there should not be any deviation between timeout during passivation and the normal path.
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nitesh Kant:


I think here lies the difference between http session passivation and ejb passivation. Since, there is a callback on passivation of bean by the container and not so in the case of http session, so i think it will be ruthless to simply remove the session without even informing the listener. Atleast the application should have some info about when the session is removed if not when passivated.


I too agree with you Nitesh , this might be the reason.But I wonder why the specification has not covered it in detail.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!