First page Back Continue Last page Graphics
Stateless Session Beans
Stateless session beans are never passivated
- Instances are pooled, interchangeable
- To reduce pool, container will remove some
Still, bean class must implement these methods
- Required by SessionBean interface
- Empty implementations are sufficient
- The methods are never actually called!
Notes:
Stateless session beans are never passivated because they are never idled by client inactivity. They are always returned to the pool after each method call. If the container determines that it has too many instances, it can conserve memory by releasing some and shrinking the pool. But this is a more permanent measure than passivation.
For stateless session beans, the two SessionBean methods are never actually called! Still, the interface requires these methods, so the bean class must have them, even if they are empty.
Stateless Session Bean as Bus
To illustrate passivation, let’s use a transportation analogy. You (the client) want to go from point A to point B in a big city. The “stateless session bean” way to do so is via bus or subway. You get on a bus, it takes you to your destination, and when you get off it goes on. It does not wait for you; it is never idle, thus never passivated. But if too many buses are in service (if the pool is too big), some may be taken off the street.