Stateless Session Beans

1· Concept & Definition

A stateless session bean (@Stateless) is a session bean that keeps no conversational state for a client between method invocations. Any instance can serve any call, so the container keeps a pool of interchangeable instances and hands one to each invocation. Each instance is used by only one thread at a time.

2· Why It Matters

• The most widely used EJB type; typical transactional service layer of Jakarta EE applications.
• Pool sizing directly limits concurrency and protects downstream resources.
• Misunderstanding "stateless" leads to data leaking between clients.

Stateless session beans are where most Jakarta EE applications keep their transaction boundaries, so their behaviour decides how commits, rollbacks and concurrency work across the whole service layer. The pool is more than an optimisation: because each instance serves one thread at a time and the pool is bounded, it quietly limits how many calls can reach the database at once, which protects the system when sized well and throttles it when sized badly. And the word "stateless" is easily misread as "has no fields", when it really means "keeps nothing for a particular client", a misunderstanding behind some of the hardest data-leak defects to diagnose.

3· How It Works

Lifecycle

Pooling

A bounded pool acts as a bulkhead: when all instances are busy, callers wait (up to a timeout) instead of overloading a database or external system. Pool size should reflect the capacity of the resources the bean uses, not the number of HTTP threads.

Stateless behavior

"Stateless" means no client-specific state survives between calls. Instance fields may hold shared, thread-safe or immutable resources (injected services, caches safe for single-thread use) but must never hold data belonging to a particular caller, because the next call — possibly from another user — may get the same instance.

Use cases

• Transactional service facades (OrderService.place) called from REST resources or web tier.
• Throttled access to constrained resources (pool as bulkhead).
• Remote business services (with remote views) in legacy distributed systems.
• Message processing logic reused by MDBs and web clients.

Deep Dive — What Happens on One Invocation

A client never holds a stateless bean instance; it holds a container proxy, and every business call takes the same path through it. The container first checks the caller's roles against any @RolesAllowed declaration. It then applies the transaction attribute, by default REQUIRED, joining the caller's JTA transaction or starting a new one. Next it acquires an instance from the pool, waiting up to the acquisition timeout if all instances are busy, and runs any interceptors bound to the method before the business method itself executes.

On the way back the order reverses. If the method returns normally or throws an application exception, the instance goes back to the pool and the transaction commits if the container started it. A system exception, meaning an unchecked exception not annotated @ApplicationException, marks the transaction for rollback, discards the instance and reaches the caller wrapped in an EJBException. Because all of this lives in the proxy, a call through this from one method to another on the same bean bypasses every step, including a different transaction attribute on the second method.

4· Java / Jakarta EE Code Examples

@Stateless
public class OrderService {
    @PersistenceContext EntityManager em;
    @Inject PaymentGateway payments;
    @Inject Event<OrderPlaced> placed;
 
    // REQUIRED: joins or starts tx
    public long place(NewOrder in) {
        Order o = Order.from(in);
        em.persist(o);
        // failure (runtime ex.) → rollback
        payments.authorise(o.total(), in.card());
        placed.fire(new OrderPlaced(o.getId()));
        return o.getId();
    }
 
    @TransactionAttribute(TransactionAttributeType.SUPPORTS)
    // read-only: no new tx needed
    public Optional<OrderDto> find(long id) {
        return Optional.ofNullable(em.find(Order.class, id)).map(OrderDto::from);
    }
}

<!-- WildFly standalone.xml: bounded pool acting as a bulkhead -->
<subsystem xmlns="urn:jboss:domain:ejb3:10.0">
    <session-bean>
        <stateless>
            <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
        </stateless>
    </session-bean>
    <pools><bean-instance-pools>
        <strict-max-pool name="slsb-strict-max-pool" max-pool-size="32"
                         instance-acquisition-timeout="5"
                                 instance-acquisition-timeout-unit="SECONDS"/>
    </bean-instance-pools></pools>
</subsystem>

// ANTI-PATTERN: client data in a stateless bean
@Stateless
public class BadCheckout {
    // shared across different clients!
    private Cart cart;
    public void add(Item i) { if (cart == null) cart = new Cart(); cart.add(i); }
}

Most of this behaviour can be reproduced with CDI, which is the usual migration target. The difference is that one shared instance serves all threads, so the pool's throttling has to be stated explicitly.

// Jakarta EE 11 CDI bean + MicroProfile Fault Tolerance
@ApplicationScoped
public class OrderService {
    @PersistenceContext EntityManager em;   // shareable container proxy
    @Inject PaymentGateway payments;

    @Transactional                          // REQUIRED by default
    @Bulkhead(32)                           // replaces the pool limit
    public long place(NewOrder in) {
        Order o = Order.from(in);
        em.persist(o);
        payments.authorise(o.total(), in.card());
        return o.getId();
    }
}
// Differences: one shared instance, so fields must be thread-safe;
// exceptions are not wrapped in EJBException; nothing is discarded.

5· Configuration, Defaults & Diagnostics

When a stateless tier slows down, look at the pool before the code. If the available count sits at zero and wait time rises, callers are queuing for instances. The next question is why: if the beans are slow because the database or an external API is slow, enlarging the pool only moves the queue downstream; if downstream has spare capacity, the pool is simply too small. A rising number of discarded instances means system exceptions are occurring, so search the logs for the matching EJBException. On WildFly the statistics are available through the management CLI.

# enable runtime statistics once
/subsystem=ejb3:write-attribute(name=statistics-enabled,value=true)

# then read one bean's pool and timing figures
cd /deployment=shop.war/subsystem=ejb3
./stateless-session-bean=OrderService:read-resource(include-runtime=true)
# check pool-available-count, pool-current-size, wait-time,
# execution-time, invocations and peak-concurrent-invocations

6· Production Usage Patterns

• Pools sized to database connection pool and external API limits.
• Read methods annotated SUPPORTS or NOT_SUPPORTED to avoid unnecessary transactions.
• Stateless beans as the target for incremental migration to @ApplicationScoped @Transactional CDI beans.

A common production arrangement is a REST resource that delegates to a stateless facade, with the facade owning the transaction and the pool sized slightly below the data source's maximum connections, so callers wait at the bean with a clear timeout instead of failing on connection acquisition. Teams modernising such systems usually convert facades one at a time to CDI beans, keeping the semantics explicit with @Transactional and a MicroProfile Fault Tolerance @Bulkhead, and verify commit and rollback behaviour with integration tests before removing the EJB module.

7· Common Pitfalls & Misconceptions

• Client state in instance fields.
• Pools larger than downstream capacity — contention moves to the database.
• Pools too small — requests queue and time out under load.
• Expecting @PreDestroy after system exceptions.

8· Best Practices

• Keep instances free of client data.
• Size pools from downstream capacity and measure wait times.
• Use explicit transaction attributes for non-default behaviour.
• Keep business methods coarse-grained.

9· Architect's Perspective & Trade-offs

10· Interview Q&A