adam bien's blog

1. Pooling is not a requirement, it is just an assumption: "...Since stateless session bean instances are typically pooled, the time of the client’s invocation of the create method need not have any direct relationship to the container’s invocation of the PostConstruct/ejbCreate method on the stateless session bean instance..."[EJB 3.1 spec, page 78]
2. EJB container can either pool the instances or create a new one for each request
3. The most important thing is, that every transaction (often request), gets an independent instance. Then you don't have to care about low level locking mechanisms. This can be achieved with or without (=creating a new instance for each request) pooling.
4. Pooling is no more needed in modern JVMs for performance reasons in general. This, however, is highly dependent on the JVM and garbage collector configuration.
5. With pools you can throttle the concurrency, because most (all I know) application servers allow you the configuration of max number of instances. You can control the concurrency of every bean type (Boundary) in a fine grained way. This is important for the avoidance of DoS attacks and dealing with legacy resources.

So pooling is not needed for performance or scalability reasons, rather than for the ease of use. You can easily restrict the scalability and you get a single threaded programming model for free. In day to day development you don't have to thing about pooling or instance management.

The only thing to remember is: every transaction runs in a dedicated Session Bean instance and thread.

[See Page 20 (EJB: Introducing Consistency) in Real World Java EE Patterns - Rethinking Best Practices book]