This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes Stateless Beans + Custom session handling VS Stateful Beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Stateless Beans + Custom session handling VS Stateful Beans" Watch "Stateless Beans + Custom session handling VS Stateful Beans" New topic

Stateless Beans + Custom session handling VS Stateful Beans

Avor Nadal
Ranch Hand

Joined: Sep 15, 2010
Posts: 136


Until now, I've developed all my Java EE applications using Stateless Session Beans only. The "only" state which I've needed to keep between method calls has been certain information about the authentication of the user, such as the user ID, login date and two or three properties more. For this task I've created my own session management, which makes a session ID after the user logins (a pseudo-random number, like many Web servers do), and stores the information associated to that ID into the database. This way, I return the session ID to the client application, so it employs this on every method call. Otherwise it would need to authenticate the user on every call, obviously.

I guess that this approach may be criticized for not taking advantage of the Stateful Sessions Beans to keep the state of the user session. But my problem is that I don't know what's the best strategy to move from my current design:

* Should I make an unique Stateful Session Bean which contain all the logic of my current Stateless Session Beans, so every method can access the user session information internally? I do not like this because it would ruin the "granularity" of my design and would make it a mess. Although I believe that a friend of me uses this design pattern (I believe he callied it "one facade design").

* Or should I leave everything as is, but make a single Stateful Session Bean simply to keep the user session state? This would implement a method to login. Then, I would pass this SFSB to the SLSB as a parameter, instead of my session ID. However, I've serious doubts about the effects of passing an object which is a stub.

Thank you.

PS: When I mention "session" I'm referring to the state of an authenticated user. Just to clarify.
Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 33132

There's nothing wrong with your current approach. Most people don't use stateful bean; especially in a web app.

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Avor Nadal
Ranch Hand

Joined: Sep 15, 2010
Posts: 136

Jeanne Boyarsky: Really? I'm happy to read that.

My implementation of a session management is really basic, since I simply store the session IDs and the related values in a database table, and check them on every user request. Of course, I also invalidate the expired sessions every X minutes. I supposse that this is not a very fast strategy compared to a session management which resides in the RAM, but until now I've only implemented simple LRU caches using the class java.util.LinkedHashMap and I have no experience with these matters.

Thank you a lot.
I agree. Here's the link:
subject: Stateless Beans + Custom session handling VS Stateful Beans
It's not a secret anymore!