EJB3 business delegates?

[meselfe]

What happens if i build a business delegate that caches the reference to the session bean? Will this lock down the session bean for as long as the reference exists. I think for stateless session beans im not guarantied that my invocation on the session bean is always serviced by the same bean instance althoug the reference is the same, correct? So is caching the reference safe? I still want my pool of session beans to service a larger number of clients than there are beans in the pool - so i dont want to lock down any particular session bean instance for one particular client.

My client is web/struts. If its possible to hold on to the business delegate with the cached reference to the session bean between http requests? Which is the beast way to do this?

[deanouk]

I'd love an answer to this.

I'm too perplexed about caching a reference to the Session bean.
Would this result in better performance?
Would it enforce the use of the same instance, thus negating the benefits of the pool?

[alrubinger]

You should absolutely cache SLSB proxies. Do the lookup once, then you may pass around and share this instance.

This is because the proxy you lookup may target *any* of the underlying bean instances in the pool. Assuming you've done a good job to ensure your SLSB has no *conversational state*, all SLSB proxies are identical from the perspective of the caller/client. This means that if your SLSB has internal instance variables, they must *not* be exposed out.

ie. Instance variables initializing some internal state for your SLSB == OK. Caching user authorization tying some bean instance to a particular request or caller == Bad.

For conversational state, use SFSB. These may not be cached in the same fashion, in that each "conversation" should reference the same SFSB instance and no others.

S,
ALR