Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Stateless SessionBean  RSS feed

 
konrad hoszowski
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
Is it possible to cache, in some way , reference to InitialContext in stateless session beans? Do I need to overriade ejbActivate method?
Thanks in advance
 
Karl Laird
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do you want to cache the InitialContext? Isnt this attempting to defeat part of the purpose of a stateless session bean?
 
konrad hoszowski
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know its against stateless session bean idea...but I need to lookup often for other EJB's and I was wondering if creating every time new InitialContext object is expensive?
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can:
1. Cache the bean's Home Interface
pro: Eliminates the JNDI lookup overhead
con: Changes in beans cause cache to go out of sync.
2. Get a Handle to the bean
pro: See above. Also eliminates creation overhead.
con: see above.
3. Grab and hold the bean's remote interface
pro: all of 2, above, plus eliminates overhead of deserialization.
con: all of 2, above, plus ties up more resources on server.
 
Rick Hightower
Author
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stateless session beans ejbActivate never gets called. The purpose of activation and passivation is to write out state to secondary storage, since stateless beans have no state, there is no need to perform activation and passivation.
A stateless bean can maintain access to an initial context.
 
Badri Iyengar
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You definitely want to cache Initial contexts on the stateless session bean. They are quite expensive to create, because there is lot of background work that is done behind the scenes. You dont want to recreate it, each time a business method is called. Stateless Sessions beans are never passivated or activated, so the non conversation state that you put on it, will be available, as long as the session bean is alive.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Badri Iyengar:
You definitely want to cache Initial contexts on the stateless session bean. They are quite expensive to create, because there is lot of background work that is done behind the scenes. You dont want to recreate it, each time a business method is called. Stateless Sessions beans are never passivated or activated, so the non conversation state that you put on it, will be available, as long as the session bean is alive.

I disagree. Benchmark the times and you will find that on most modern J2EE Servers the cost of creating an InitialContext and/or the lookup of a local home interface is trivial.
If you really want to cache the InitialContext/home interface then it is certainly possible and is a very popular approach. However, this should not be managed in the ejb. It should be the job of an EJB Home Factory. This is actually a Pattern identified in EJB Design Patterns: Advanced Patterns, Processes, and Idioms. Here is a link to an article on developerWorks that discusses this topic.
[ July 09, 2003: Message edited by: Chris Mathews ]
 
Edy Yu
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"1. Cache the bean's Home Interface
pro: Eliminates the JNDI lookup overhead
con: Changes in beans cause cache to go out of sync." by Tim Holloway.
I am wondering for stateless session bean, how Changes in beans can cause cache to go out of sync?
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am wondering for stateless session bean, how Changes in beans can cause cache to go out of sync?

If you redeploy a new version of the EJB, the EJBHome object in the cache is still trying to create instances of the old EJB. If you hadn't cached the home, your client would fetch the correct version of the home object from the JNDI tree.
 
Edy Yu
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"If you redeploy a new version of the EJB, the EJBHome object in the cache is still trying to create instances of the old EJB. If you hadn't cached the home, your client would fetch the correct version of the home object from the JNDI tree"
After we redeploy a new version of stateless session bean, there should be a new set of bean instances in the pool. Where are the old bean instances? If they are gone, by calling home.create() will grad a new instance in stead of the old one (provide the APIs are not changed...). So I think the problem goes to where are the old bean instances?
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So I think the problem goes to where are the old bean instances?

If you really redeploy an EJB, it replaces the previous version as in "redeploy = undeploy + deploy". The undeployment part basically removes the existing instances and the home object bound to the JNDI tree.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!