Head First EJB

AdviceStatefulBean CLIENT code

The stateful version of the client adds two things not in the stateless version:

1. We’re passing an argument to the create() method.

   A stateful bean can (and often does) have arguments to create methods, so that the client can pass in client-specific state for the bean to save and use in later “conversations” with the client (i.e. later method calls from that client).

2. We’re calling remove() on the component interface.

   It’s polite for the client to tell the Container that she’s done with a stateful session bean. And now you know why. Without the remove() call, the Container will hold on to the bean, wastefully, until the bean times out. So in this case “polite” really means “improves scalability”.

   

Note

You must be able to recognize whether the client is for a stateful bean.

You must be able to look at client code, like this, and know whether the client’s bean is stateful. If the client calls a no-arg create(), there’s no way to know whether it IS stateless, but at least you know it MIGHT be. If the create has args, or a name other than create() (like, createAccount()), you know the bean must be stateful.

Sharpen your pencil

Do the interfaces have to change when it goes from stateless to stateful?

Look at the two interfaces below, for the stateless version of the Advice bean. If needed, make any adjustments to the code in either or both of the interfaces, for what ...