Why use stateful session beans?

Question

I\'m learning EJB3 and I\'m just curious when it\'s convenient to use SFSB? I can\'t find any nice example when SFSB realy solve easily some complex problem.

Actuall

Answer 1

I'm learning ejb3 and I'm just curious when it's convinient to use SFSB? I can't find any nice example when SFSB realy solve easily some complex problem.

You mean like a shopping cart? That's the obvious answer that I can think of.

Actually I see that SLSB can be used as web-services and this is convenient.

You can think of EJBs as one way to deploy distributed services, but be careful. The term "web services" makes most people think of "SOAP-based web services using HTTP protocol", and that's not what you have in a SFSB.

But I don't know when to use SFSB. I see only problems with it because we should learn something about it, we should write code which consists of annotations a bit less then completely, we should use annoying lookup.. And we don't get anything good in return.

This paragraph is confusing, but I think you're saying you don't like EJBs much.

For example, we can't use SFSB from SLSB because stateful objects can be used only from stateful context.

Right, they're complementary. You use SFSB for use cases that require - wait for it - state to be maintained between calls.

We can't use DI in servlets, instead of it we should manually create SFSB instance using lookup and then put it to HttpSession object. It can't be a web-service.

Where did servlets come from here?

The only profit I can see in SFSB is a transaction management. But I think it's rare case when we really need a transaction and we don't need DB. I can suppose that it can be realy useful when we store our data in xml-file and use transaction management in SFSB to simulate nonrelational DB.

I think you're totally off base here. Sessions beans are the ones that know about units of work and managing transactions. They probably have to work with entity beans to persist some of that state when the use case is done, so transactions aren't as uncommon as you seem to think.

I'm almost sure that I'm totally wrong, so give me some realy nice examples of SFSB usage.

What's your expectation? That someone will post working SFSB? I'm not going to do that, mostly because I'm not a big EJB fan. (I do everything you're alluding to and more with Spring.)

But rest assured that SFSB are sometimes useful. The shopping cart is the obvious example. You need a place to maintain items in the cart until the customer decides to purchase. SFSB is one way to accomplish that.

Answer 2

it is just a matter of design to choose between a stateful and a stateless architecture.

most of the times stateless design is preferred since it is easier.

although simpler to understand at the beginning, building stateless applications leads to a set of problems (plenty of stateless web services, spring singleton, etc...), making the application less manageable in the long run.

i prefer to design stateful applications when possible.

stateful session bean is a way to do it. spring prototype or web-scoped bean another.

check also out jboss seam framework.