Head First EJB

Stateless session beans are more scalable

Clients don’t share EJBObjects, but the same bean can service multiple EJBObjects. Just not at the same time. A single bean can handle multiple clients, as long as only one client at a time is in the middle of a business method invocation.

The bean comes out of the pool ONLY when a client invokes a business method on the EJBObject stub. So, a single bean can jump out to handle one client’s call, then jump back in the pool, then jump out to handle a different client’s call, and then jump back in the pool...

Brain Power

Why does the “pool” architecture work to make stateless session beans more scalable, but not stateful session beans? Why can’t stateful session beans use the bean pool?

There are no Dumb Questions

Q:	Q: Here’s something that is REALLY starting to annoy me... why do you have a Component interface and a Home interface when the Remote objects are called the Home and the EJBObject? Why isn’t it just the EJBObject interface and the HomeObject interface? Or the Home and the EJB interfaces? Why the inconsistency?
A:	A: Actually, that really pisses us off too. But you’ll get used to it. Be thankful, it was even worse if you learned EJB prior to version 2.0 when it was called the Home and the Remote. Now that was a real problem because, first of all, both the Home and the Remote were Remote in the java.rmi sense. Second, as of EJB 2.0 you can ...