This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Stateless Bean calling Stateful Bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Stateless Bean calling Stateful Bean" Watch "Stateless Bean calling Stateful Bean" New topic

Stateless Bean calling Stateful Bean

jawle jaw

Joined: Nov 11, 2004
Posts: 3
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.
[ November 11, 2004: Message edited by: jawle jaw ]
kevin zhou

Joined: Oct 28, 2004
Posts: 6
The application's state is maintained by stateful EJB. Although the stateless EJB instance maybe different at each invocation, it's sure to call the same stateful ejb instance. That's how it works.
Eduardo Rodrigues
Ranch Hand

Joined: Jul 01, 2003
Posts: 199
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...

Eduardo Rodrigues<br />SCJP 1.4/5.0 SCWCD 1.3/1.4, SCBCD 1.3, SCMAD, SCEA<br />IBM 484 & 486<br />Belo Horizonte<br />Minas Gerais<br />Brasil
jawle jaw

Joined: Nov 11, 2004
Posts: 3
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??
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
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.
I agree. Here's the link:
subject: Stateless Bean calling Stateful Bean
It's not a secret anymore!