Head First EJB

Session beans can be stateless or stateful

We’ll go over all this in detail in the Session Bean chapter. For now, you need to know that session beans can be marked (at deployment time) as either stateless or stateful.

A stateful bean can remember conversational state between method calls, while a stateless bean won’t remember anything about the client between method invocations.

The phrase “conversational state” really means “client-specific state”, and a typical example is a shopping cart. It wouldn’t be fun if you (the shopper) got a cart, put something in, but then when you go to put the second thing in, the first thing vanishes from the cart. Not too user-friendly. So, a good shopping cart will keep the client shopper state (i.e. the items in the cart) for as long as the shopping session is alive. (We’ll explain what we mean by alive in the Session Bean chapter.)

Stateless beans simply forget about the client once the method call completes. So, stateless beans are for services that don’t require a continued conversation between the client and the service. That doesn’t mean the client won’t keep calling methods on the stateless bean, but it does mean that the client can’t depend on the bean remembering anything about the previous method calls.

Watch it!

Stateless beans CAN have state! (Just not client-specific state.)

Some people think “stateless” means “no state”. A stateless bean can have instance variables like any other object; it just can’t use them to maintain values specific to a particular client.

There are no Dumb Questions

Q:

Q: I’ve heard that only stateless session beans are scalable, and that nobody should ever use stateful session beans. Is that true?

A:

A: No, not completely. It is true that stateless session beans are generally more scalable than stateful session beans because of the way stateless beans are managed by the container. You’ll see the reasons for this in the Session Bean chapter. But... that doesn’t mean you should never use stateful beans. You should consider stateful beans when you need conversational state, and when the alternatives for saving that state (like using the client to store state, or using a servlet to store state, or using a database to store state between each method call from the client) are more of a performance hit than the less-scalable nature of stateful session beans.

Make it Stick

An entity bean IS something. A session bean DOES something.

Sharpen your pencil

Know your bean types.

Look at the problem description on the left, and put a check mark for the bean type that would best fit the problem. There isn’t one perfect right answer for these... you might decide that one bean type will work if you approach it one way, but another bean will work if you solve the problem in a different way.

	Entity	Message-driven	Session bean (circle stateless, stateful, or both)
Booking a ticket for a rock concert				stateful	stateless
A bank account				stateful	stateless
Searching a product database				stateful	stateless
Dating service match-ups				stateful	stateless
Receiving submitted expense reports, and sending them out for approval				stateful	stateless
Online expert diagnosis—you describe a symptom and the system helps you determine the cause				stateful	stateless
The books in a library				stateful	stateless

Overheard at the Tikuibean Lounge

• Session bean: I’m so tired of doing all the work and getting none of the glory.

• Bartender: What do you mean “none of the glory’”? Aren’t you the only bean that’s been required by the spec since the very beginning? Since EJB 1.0?

• Session bean: Fat lot of good THAT does me. All anyone wants to talk about now is entity beans. Entity beans, entity beans, entity beans. Not that I don’t like them—some of my best friends are entity beans, but I wish people would talk about what I do.

• Bartender: Now that you mention it, entity beans are mostly what folks talk about here at the bar, what with the big CMP improvements in EJB 2.0.

• Session bean: And that’s another thing... what is the Big Deal with CMP? It’s just going to a database! Seriously, tell me WHAT is so special about that? “Ooohhh look! It updated a record!” Please.

• Bartender: Yeah, but the programmers around here seem to like not having to do all the database code now. And there’s something about persistent relationships, I just can’t quite remember...

• Session bean: CMR. Container-managed relationships. OK, even I have to admit that CMR makes things a lot easier for developers. But that’s not what bugs me—I KNOW everybody likes entity beans, but what about ME? What about everything I do? Entity beans represent things in the system, but without me, those things don’t do much. Maybe an entity has some getters and setters and some queries, sure, but not a lot of business logic. To use entity beans in an app, you pretty much HAVE to use session beans to do the business processing. Like, an entity bean might represent the drinks you sell here, and the individual customers, but what good are drinks and customers without a bartender? You need someone to actually put the entities (the drinks and the customers) together in a meaningful way! And that’s what session beans do. We do the deals. We work with the client to get something done, while entities just sit there waiting for session beans to use them. Hey, can I get another one of those? And don’t even get me started on message-driven beans...

[To be continued.]

Bullet Poinet

• EJB is a component-based development model.

• Components are reusable chunks of functionality you can modify for different applications without touching the java source code.

• One benefit of EJB is WODA—Write-Once-Deploy-Anywhere. You can deploy your EJB 2.0 components to any app server that’s EJB 2.0-compliant.

• WODA means you have to learn only one, standard API rather than proprietary vendor-specific APIs.

• The EJB architecture uses an EJBObject to intercept client calls to a bean. This gives the server/container a chance to step in and add services.

• EJB services include transactions, security, resource management, networking, and persistence.

• Beans come in three flavors: Entity, Session, and Message-driven.

• Entity beans represent a uniquely identifiable thing in a persistent store; usually that means a row in a database table.

• Message-driven beans are JMS messaging service consumers.

• Session beans are... everything else.

• Session beans can be stateful or stateless.

• Stateful beans can remember “conversational state” with a client, while stateless beans cannot.