• Post Reply Bookmark Topic Watch Topic
  • New Topic

Where to put the home call  RSS feed

 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my trading application, we have a bunch of EJBs which call each other. For example, when an order is placed, a message-driven bean receives it, and then about 4-5 stateless session beans are called (either directly from the MDB, or by the other session beans called by the MDB).
The following questions are asked in the context of the server, so all calls and interfaces are local.
As I understand it, there is a high cost of doing a lookup on the home interface, and a relatively low cost on getting the remote interface (which is all local on the EJB server).
It would be nice if I can do all the home lookups in one place, when the bean is first loaded onto the server and simply cache the references. ejbCreate() would feel like the right place, except from what I understand, this method is called every time I call create() on the bean, so I'd be retaking the lookup hit. Is there any place to cache these references in a stateless session bean?
More generally, how to I minimize the cost of home lookups on the server?
--Mark
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Herschberg:
As I understand it, there is a high cost of doing a lookup on the home interface, and a relatively low cost on getting the remote interface (which is all local on the EJB server).

Actually the cost is not that high...
Originally posted by Mark Herschberg:
More generally, how to I minimize the cost of home lookups on the server?

First I would determine if performance was a problem, if not than I would probably just leave it alone. Otherwise, a simple Factory class for all lookups will do the trick. In J2EE Patterns talk this is called a Service Locator. Within the Service Locator you can perform the lookup and cache the reference on first use. There is a pattern in EJB Design Patterns aimed specifically at this problem called EJBHomeFactory. It is worth a look...
[ February 27, 2003: Message edited by: Chris Mathews ]
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, so we're using a ServiceLocator for the client, and it makes sense there--basically a convienent place to keep all EJB refernences. When I start up my client, I create an instance of the service locator, and subsequently call it.
I'm not so clear on how to do this on the server. Who creates the ServiceLocator? How do you find it? Do you create a singleton? Somehow that doesn't feel like the right thing to do on an EJB server. We could create an instance and bind it to a JNDI name, but then, do we simply hard code the JNDI lookup for this object?
--Mark
 
Dana Hanna
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The proper way to do this is in the ejbCreate() method. In a stateless session bean, these are already being cached for you. When you call create() on the home interface, ejbCreate() is not nessecarily called. It is up to the vendor, but I can't imagine and modern day vendor not caching a stateless session bean. The lifecycle says that they are returned to method ready state after a call completes. After all, it's what makes them so handy .
To sum it up - Most likely these are pooled and expired after x minutes. calling create(0 does NOT always call ejbCreate(). Run performance testing with logs if you need to set your heart at ease, and avoid using a ServiceLocator in the EJB container. The container should provide that for you!
[ February 28, 2003: Message edited by: Dana Hanna ]
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dana Hanna:
avoid using a ServiceLocator in the EJB container.

Why? The lookup of an EJBHome within the context of another EJB is just as suited for ServiceLocator as any other client.
[ March 01, 2003: Message edited by: Chris Mathews ]
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Herschberg:
I'm not so clear on how to do this on the server. Who creates the ServiceLocator? How do you find it? Do you create a singleton? Somehow that doesn't feel like the right thing to do on an EJB server. We could create an instance and bind it to a JNDI name, but then, do we simply hard code the JNDI lookup for this object?

Implementing the ServiceLocator as a Singleton is a valid choice. In most cases I stay away from Singletons due to complications with clustered environments. However, in this case we don't care if there are many instances of the ServiceLocator among nodes, we just want a convenient way to access the ServiceLocator from our ejbs within each node. In general, I don't like Singletons but I don't see any harm in using them in this scenario.
The other choice is to have each ejb create an instance of the ServiceLocator when it is first created. This means that each ejb has a separate cache but that should not be a big deal either.
 
Dana Hanna
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, of course you could create a ServiceLocator within the container, but the container should be doing that for you. It's my understanding that a local EJB reference tag and doing this in the ejbCreate method is how the spec defines this happening.
Do some performance testing and you'll see that the lookup truly isn't that costly, and isn't called much at all due to object pooling.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!