Stateless vs Stateful Bean

[delphi'sghost]

Now my understanding of stateful vs Stateless session beans is that stateful ones contain state, and stateless beans don't, and are just worker beans that perform tasks.

However, Seam kind of blurs the lines between the two since any state can be held outside the bean as a context variable and in/outjected as needed.

A search screen may have a criteria object for holding search params, and a result list. You can biject both these items into the search bean and have it as a stateless bean, or you can make the results and the criteria accessible only as members of a stateful bean. Ignore for now the issue of injecting an extended persistence context into the stateless bean (we can use a Seam managed PC)

If I understand it correctly, a stateless bean may only have a few instances shared by multiple users (depending on the container implementation) since it carries no state, while a stateful bean is a 'one per user' bean.

Looking from a memory use perspective. A stateful bean only ever needs 1 string for the variable name, and one pointer for the reference to the bean. Stateless beans with bijected state require one string, and one pointer per bijected member.

I seem to recall reading that it was unwise to use bijection excessively, especially in a clustered environment which would be a plus in the stateful bean column (however, I can't find that comment now in the seam docs). The documents also warn about binding an entity bean to a conversational or session scoped seam context variable, opting to hold a reference to it in the stateful session bean instead.

So the question is, is it better to biject state, or is there value in holding state in a stateful bean?

[dro_k]

I am in the same situation... does anyone know the answer to this one? What's the best practice. To use Stateless Session Beans + Injected Beans from HTTPSession/Conversation/etc for keeping the state or keeping the state in a Stateful Session bean?

[pmuir]

My rule is to use a stateful bean if I need to hold state between accesses to the bean.

[damianharvey]

Pete,

What advantages does that have over:
a) a Conversation scoped Stateless Bean.
b) a Conversation scoped JavaBean.

I'm finding it hard to justify using Stateful Beans for anything.

Cheers,

Damian.

[pmuir]

a) I don't think this works ;) - you will find (AFAIK) that any non-bijected fields are lost/wrong between requests (remember stateless beans are assigned from a pool, so this may *not* show up under low load).
b) Not as efficient in a clustered environment (yes, Seam provides support for clustering javabeans, but it's not as good as that provided by EJB3).

Reasons not to use SLSB/SFSB - needing a local interface which is a pita :)

[pmuir]

Yes, so in reality I tend to use javabeans as I'm normally not considering clustered environments and don't want interfaces cluttering things up!

[fquimbay]

Greetings, Pete ...

About your last post, what other considerations do I have to take account, in case I develop an application with JBoss Seam for an clustering enviroment? I don't know... if I take care of this aspect, with SLSB/SFSB, Entity Beans or Seam Pojos for an clustering environment ? Thanks, for your help.

--
fabio quimbay