Hi, I would like to know why one would use a stateless session bean rather than a http session to track the 'session' of a browser based user? The only reason I can think of to use a stateless session bean is if I want to persist session-related information to a database. Are there any other reasons, or is there something I'm missing?
Well one other decision that might factor into this decision has to do with performance. In the olden days, and maybe still today, keeping session information persistent would use up a little more memory, and be slow. Now they have definitely made improvements, but sometimes that performance hit was too much. So by using a Stateless Session object, you had a pool of these objects that could act for any client, not just the one client that create the "Session". So in the one par twhere a session is persisten, each client must have it's own Session object and own it till the session ended. In a Stateless Session, this object is always either performing for a client, or in the Pool state ready to work for any other client that calls it. And if you really had to save the session, storing it in an Entity Bean or other persistent solution would be available. So, what I am saying is it basically is a design decision based on what needs to be done, and what are the performance goals. Hope that helps a little. Mark