I have seen in this forum people talking about Stateless Bean calling Stateful Bean. I could not comprehend this. If a client is calling SLSB and everytime the call is made, it would a different SLSB instance. How could the client state maintained here e.g. shopping cart (unless special logic is added). Because the next SLSB instance doesn't know which SFSB instance to call. Can somebody clarify me on this. Thanks. [ November 11, 2004: Message edited by: jawle jaw ]
What? If the client of a stateful bean is a stateless bean, the session will be lost every invocation, no??? Where will you store the reference for the stateful??? On the web tier??? If you don�t store I think you�ve lost your stateful reference because you can�t store in a member of the stateless bean... Bye
Thanks for the reply. The fact is SLSB doesn't store state and SFSB stores state. If we have to maintain state for a client invocation (so that the state is available for the next call), the client should call directly the SFSB. The client should not call the SFSB via SLSB. The pet store example the EJBController is a SFSB, I believe for the very reason. Here the advantage is, it is the single interface all client requests are sent to (EJBController forwards to other EJBs), but the disadvantage is all the client calls (even some them don't need state to be maintained) are going through SFSB that doesn't help in scalability. So which one would be better, single interface or scalability? I would go with mutliple session beans exposed to clients, if it helps in scalability. What do you think guys??
Finally, a reference of the SFSB should be kept at web tier and then next time it can be used. If a call starts from web tier, through SLSB, and the SFSB reference returned to the web tier and kept, I think no harm for everyone.