Win a copy of Modern JavaScript for the Impatient this week in the Server-Side JavaScript and NodeJS 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

EJB look up

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

How we can cutomise and optimise EJB look up ?

I know this is probably the dumbest question on EJB, but I would like to know what do I need to do ? Shall i use one properties file to say where to look up for a specific bean like jndiname = IIOP://machine ort

If i'm using this properties file,for the lookup method how i can get the context associated with each bean? Will the setting of environment properties make sense?

Thanks,
Lima
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Elizabath,


Shall i use one properties file to say where to look up for a specific bean like jndiname = IIOP://machine ort


There are two distinct situations: one is when your clients are remotely located (stand alone or RMI clients) and another one is when they are collocated with your EJBs (like a servlet or jsp looking up an ejb). In the first scenario you have to understand that looking up ejbs to jndi is a quite expensive operation. It involves RMI calls (including marshalling & demarshalling parameters as well as network traffic). It makes sense though to reduce your jndi calls in that case. One design pattern that you can use is the home cache factory design pattern. Another thing worth noting is that most of the time your clients (standalone or not) will deal with a cluster of server instances. If you specify one server or another in the cluster for the initial lookup, it won�t make any difference though. Your container will maintain a cluster-aware jndi tree (and each instance maintains a local copy) and the real server that your lookup is using will actually be unknown. The container will actually load balance the request in order to achieve better performances.
In case you have collocated clients you need no properties whatsoever. The container will always lookup the ejbs making local calls. Although you�ll write code to specifically instruct the container to lookup the ejb on another machine, it will use something named optimization algorithms for collocated objects and for obvious performance gain will never leave the current instance.


If i'm using this properties file,for the lookup method how i can get the context associated with each bean? Will the setting of environment properties make sense?


I guess is not clear to me what you mean by this. If the above answer doesn�t make things clear for you, please try to explain this in more details.
Regards.
 
Don't play dumb with me! But you can try this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic