6 Replies Latest reply on Aug 8, 2007 12:41 AM by fabio quimbay

    Stateless vs Stateful Bean

    Andy Gibson Novice

      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?