I have a pretty simple EJB design consisting of a facade bean that is made available to rich clients. The facade then calls on a few worker beans to actually process the business methods. All of my beans are stateless session beans. My question is this: Since a stateless session bean is always "hanging out" in method-ready state, could the facade bean look up the worker beans in the ejbCreate() method and just keep them as local variables? Would this save having to look up the appropriate worker bean for every method call? Or, will this create different problems that I haven't thought of?

BTW, I'm running iPlanet App Server 6.0, SP 2.

Thanks.

It is considered more robust to keep handles, not EJB stubs themselves. So you can cache the handle of a looked-up bean - asking handle for a stub is supposed to go much faster than any lookup.

You can keep the actual session bean references in your bean. Just remember to hold a seperate reference in each session bean instance - the EJBObject reference is not guaranteed to be multithread-safe.

I don't see a reason why holding handles would be any more robust. Holding a reference is a much more common idiom (see Blueprints, for instance). Would Curumo care to explain this in detail?

Gal

My understanding is that handles are robust in case you want to pass references around for the looked up bean. This could mean across different VMs. Any thoughts on that?

Yes, that's what it is all about - passing around. Handles are Serializable - that the first and most important requirement for objects you transfer through remote calls. If you have one and only one server - there's no difference between remote stubs and handles, that's true. However 'robust' means - no need to change your code if...