stateful session bean pool size

Question

am going through enterprise session bean material.i have doubts regarding below oints :-

1) lets say we mentioned the pool size as 50 for some statful session bean. Different 50 clients use them . so now all the 50 beans maintain some state. At what point of time will these states be removed so that if 51th clien ask for bean it does not get any previous spoilt state.?

2) lets say we mentioned the pool size as 50 for some stateless session bean and all are in use at some point of time. If 51th client comes and ask for a bean, will that wait till some bean become free or create new bean instance?

Answer 1

Stateful session beans are not normally pooled. It's possible, but their state makes them less ideal to pool as the client expects a fresh bean when obtaining a reference.

For stateless beans, yes the 51st client will have to wait. This is normally a good thing since it automatically moderates the resource consumption of your system. Depending on the resources you have, your workload and the amount of work being to in a single call to a ssb, you might want to tune the size of your pool.

Answer 2

As bkail states the pooling semantics of @Stateless beans are vendor-specific. That said in EJB 3.1 we added the @AccessTimeout annotation which can be used on the bean class or methods of a @Stateless, @Stateful or @Singleton bean.

@AccessTimeout

In a general sense this annotation portably specifies up to how long a caller will wait if a wait condition occurs with concurrent access. Specific to each bean type, wait conditions will occur when:

• @Singleton - an @Lock(WRITE) method is being invoked and container-managed concurrency is being used. All methods are @Lock(WRITE) by default.
• @Stateful - any method of the instance is being invoked and a second invocation occurs. OR the @Stateful bean is in a transaction and the caller is invoking it from outside that transaction.
• @Stateless - no instances are available in the pool. As noted, however, pooling sematics, if any, are not covered by the spec. If the vendor's pooling semantics do involve a wait condition, the @AccessTimeout should apply.

Usage

The @AccessTimeout is simply a convenience wrapper around the long and TimeUnit tuples commonly used in the java.util.concurrent API.

import java.util.concurrent.TimeUnit;
@Target({METHOD, TYPE})
@Retention(RUNTIME)
public @interface AccessTimeout {
    long value();
    TimeUnit unit() default TimeUnit.MILLISECONDS; 
}

When explicitly set on a bean class or method, it has three possible meanings:

• @AccessTimeout(-1) - Never timeout, wait as long as it takes. Potentially forever.
• @AccessTimeout(0) - Never wait. Immediately throw ConcurrentAccessException if a wait condition would have occurred.
• @AccessTimout(30, TimeUnit.SECONDS) - Wait up to 30 seconds if a wait condition occurs. After that, throw ConcurrentAccessTimeoutExcpetion

No standard default

Note that the value attribute has no default. This was intentional and intended to communicate that if @AccessTimeout is not explicitly used, the behavior you get is vendor-specific.

Some vendors will wait for a preconfigured time and throw javax.ejb.ConcurrentAccessException, some vendors will throw it immediately. When we were defining this annotation it became clear that all of us vendors were doing things a bit differently and enforcing a default would cause problems for existing apps.

On a similar note, prior to EJB 3.0 there was no default transaction attribute and it was different for every vendor. Thank goodness EJB 3.0 was different enough that we could finally say, "For EJB 3.0 beans the default is REQUIRED."