Pooling is still mentioned in the EJB 3.1 / Java EE 6 specification. The question is: do you have to care? The answers are:
- 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]
- EJB container can either pool the instances or create a new one for each request
- 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.
- 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.
- 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.
NEW MUC Airport Workshop: Migrating Java Client (Swing / Java FX) to Web Standards