I use the Business Delegate to hide the implementation details (lookup, EJB, etc.) of the Business Service from the client. The same Business Delegate is used in many different places in the client. Now I would like to avoid to pass around the object reference of the Business Delegate in the client.
I wonder if the Business Delegate should be a Singleton. Is this reasonable?
Thank you.
I think it can be, if you want to cache the EJB that it uses. The Core Patterns implementation isn't a singleton but by allowing you to flatten the Handle object from the delegate, it allows the client to cache the value and subsequent calls to the delegate can avoid the lookup and creation of the session bean.
Typically, all you'll be getting from the particular delegate (actually, it's more of a factory) is Home objects to SLSB, which are almost immediately "discarded" (more politely put would probably be "ignored") by the clients as they get their own Remote objects. All those clients have to wait on the container to return the Remote objects (via the separate invocations of create()), so threading is automagically handled by the container - which is exactly what it's there fore.
You shouldn't cache the Home, either - cache the HomeHandle (it's serializable, for one).
When you (attempt) to cache the EJBObject (the RemoteInterface implementation), you're caching an actual network-bound resource. That means you're attempting to lock into a specific EJB. There are lots of bad/interesting things that can happen. For example, what happens if the bean the Remote is referencing is passivate or even removed from the pool? Uh, oh...
The EJBHome object, on the other hand, is a means of obtaining the network-bound resource. Now, EJBHomes themselves are bound, but they are not tied directly to the resources inside the container - they don't reference EJBs.
That should provide enough food for thought...
excellent, thanks for your comments.
so to the orginal question, would you agree with the comments below?
The pattern catalog describes the business delegate as containing an instance of an EJBObject where as the service locator can optionally cache an EJBHome object. The former avoids repeated JNDI lookups and creating an EJB whilst the later just avoids repeated JNDI lookups.
Using this strategy, the delegate looks up the home interface and creates an instance of an EJB on creation; it has a one-to-one relationship with it. You dont really want the delegate to have to create an EJB from the home interface in every method so it should therefore contain an instance member.
This all means the delegate can t be a singleton, it can't share that EJBObject with multiple clients.
Essentially, that is correct - the function of the Business Delegate is to "front" (or delegate to) the SessionBean. It may keep the EJBObject as an instance variable, but you have to make sure that the BD instance itself is not somehow cached in memory for the reasons listed above. Typically, the EJBHome is cached either as a static member in the BD or in a Singleton "HomeFactory", reducing the overhead of the JNDI lookup. Here's some home-brew numbers to give you an idea of the (relative) performance (each action was performed in loops of 10,000 iterations):
JNDI lookup/narrow:4 msec
EJB create():1 msec
Get HomeHandle: 0 msec (basically not measureable!)
Get EJBHome from handle: 0 msec (ditto)
Just to go back to this... if the delegate were a singleton, it would contain a single EJBObject reference and all clients would access this, are there any issues if the EJB were a stateless session bean? Wouldn't the container handle this and fulfill the call to the EJB efficently? ie the container would manage what actual SLSB is accessed and there would be no multipl client isses?
