• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Stateless SessionBean

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Author
Posts: 350
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
I didn't do it. You can't prove it. Nobody saw me. The sheep are lying! This tiny ad is my witness!
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic