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?
My rule is to use a stateful bean if I need to hold state between accesses to the bean.
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.
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 :)
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!
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.