EJB — Enterprise JavaBeans

What is EJB — and Why Does It Matter in 2025?

EJB (Enterprise JavaBeans) is a server-side component model that was the dominant way to build enterprise Java applications from roughly 1999 to 2010. An EJB is a CDI bean with additional container- managed services baked in: distributed transactions, declarative security, connection pooling, instance pooling, remote invocation, and scheduling — all without writing a line of infrastructure code.

EJBs are not dead. They are dead in new projects. Banking systems, insurance platforms, government portals, and telecom backends built between 2000 and 2015 run on WildFly, Payara, and WebSphere serving millions of transactions daily — and they are full of EJBs. A senior Java developer entering one of those environments without knowing what @Stateless, @TransactionAttribute, or @MessageDriven mean is walking in blind.

Why EJB 2.x Was Painful — and Why EJB 3 Came Too Late

/*
 * EJB 2.x (1999–2006) — what developers actually had to write:
 *
 * 1. A Remote interface (what remote callers see)
 * 2. A Local interface (what local callers see)
 * 3. A Home interface (factory for the bean)
 * 4. The bean implementation class (extending EntityBean or SessionBean)
 * 5. A deployment descriptor (ejb-jar.xml) — hundreds of lines of XML
 * 6. Vendor-specific XML for each app server (jboss.xml, weblogic-ejb-jar.xml...)
 *
 * For a simple CRUD service: 5+ files, ~500 lines of boilerplate.
 * For a domain with 20 entities: 100+ files before writing business logic.
 *
 * EJB 3.0 (2006) replaced all of this with:
 */

@Stateless  // that's it. One annotation.
public class ProductService {
    @PersistenceContext
    private EntityManager em;

    public Product find(Long id) {
        return em.find(Product.class, id);
    }
}

/*
 * EJB 3 was genuinely good. The problem: Spring had already won.
 * By 2006, most greenfield enterprise Java was Spring-based.
 * EJB 3's elegance arrived at market too late to reclaim developers.
 */

Session Bean Types — What You'll See in Legacy Code

@Stateless — the workhorse (most common)

@Stateless
public class OrderService {

    @PersistenceContext
    private EntityManager em;

    @Inject
    private PaymentGateway gateway;

    // Transaction starts automatically when this method is called.
    // If it returns normally → COMMIT. If it throws RuntimeException → ROLLBACK.
    public Order placeOrder(Cart cart, PaymentDetails payment) {
        Order order = new Order(cart);
        em.persist(order);                   // persisted in the same transaction
        gateway.charge(payment, cart.total()); // if this throws, order.persist() rolls back too
        return order;
    }
}

/*
 * The container maintains a POOL of @Stateless instances.
 * Under load: pool grows. At rest: pool shrinks.
 * No client holds a reference to a specific instance between calls.
 * Equivalent to Spring's @Service (singleton by default, stateless by convention).
 */

@Stateful — one instance per client conversation

@Stateful
public class ShoppingCart {

    private final List<CartItem> items = new ArrayList<>();

    public void add(Product product, int qty) {
        items.add(new CartItem(product, qty));
    }

    public BigDecimal total() {
        return items.stream()
            .map(CartItem::subtotal)
            .reduce(BigDecimal.ZERO, BigDecimal::add);
    }

    @Remove  // client calls this to signal "I'm done, destroy this bean"
    public Order checkout(PaymentDetails payment) {
        // final order processing
        return orderService.placeOrder(items, payment);
    }

    @PreDestroy
    public void cleanup() {
        // called by container after @Remove or on session timeout
    }
}

@Singleton — one shared instance with controlled concurrency

@Singleton
@Startup   // eagerly initialized at deployment, not on first access
public class AppConfigCache {

    private Map<String, String> config;

    @PostConstruct
    public void init() {
        config = loadFromDatabase();  // runs once at startup
    }

    // @Lock(LockType.READ) — multiple threads can call simultaneously (default for reads)
    @Lock(LockType.READ)
    public String get(String key) {
        return config.get(key);
    }

    // @Lock(LockType.WRITE) — exclusive access, blocks all reads and writes
    @Lock(LockType.WRITE)
    public void refresh() {
        config = loadFromDatabase();
    }
}

/*
 * Spring equivalent: @Component + @ApplicationScope (CDI) or a Spring singleton bean
 * with explicit synchronization or ReadWriteLock.
 * @Singleton EJB gives you the read/write lock semantics declaratively.
 */

Transaction Management — The Feature EJBs Did Best

Declarative transaction management is the feature that made EJBs genuinely valuable — and it's the one Spring copied most directly. Every EJB method has a transaction attribute that controls how it participates in an existing transaction or creates a new one:

@Stateless
public class PaymentService {

    // REQUIRED (default): join existing TX, or start a new one if none exists
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void processPayment(Order order) { ... }

    // REQUIRES_NEW: always start a NEW transaction, suspend any existing one
    // Use for audit logging that must commit even if the calling TX rolls back
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void logPaymentAttempt(Order order, String result) { ... }

    // NOT_SUPPORTED: suspend any existing TX, run without one
    // Use for operations that must NOT participate in a TX (some bulk reads)
    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    public List<Order> exportAll() { ... }

    // MANDATORY: must be called within an existing TX, throws if none
    @TransactionAttribute(TransactionAttributeType.MANDATORY)
    public void deductInventory(Order order) { ... }
}

Message-Driven Beans — Async Processing via JMS

A Message-Driven Bean (MDB) is an EJB that listens to a JMS queue or topic and processes messages asynchronously. It's the Jakarta EE answer to "I need to process work off the request thread without polling." In modern systems this role is filled by Kafka consumers or Spring's @JmsListener — but MDBs are widespread in legacy banking and payment systems.

import jakarta.ejb.MessageDriven;
import jakarta.jms.*;

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationType",   propertyValue = "jakarta.jms.Queue"),
    @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "java:/jms/queue/OrderQueue"),
    @ActivationConfigProperty(propertyName = "acknowledgeMode",   propertyValue = "Auto-acknowledge")
})
public class OrderProcessingMDB implements MessageListener {

    @Inject
    private OrderService orderService;

    @Override
    public void onMessage(Message message) {
        try {
            TextMessage textMsg = (TextMessage) message;
            Long orderId = Long.parseLong(textMsg.getText());
            orderService.processOrder(orderId);
            // container auto-acknowledges on successful return
        } catch (JMSException e) {
            throw new RuntimeException("Failed to process message", e);
            // RuntimeException causes the container to NOT acknowledge → message redelivered
        }
    }
}

Scheduling and Async — Still Useful Patterns

// @Schedule — declarative cron scheduling on @Singleton EJBs
@Singleton
public class MaintenanceScheduler {

    @Schedule(hour = "2", minute = "0", persistent = false)
    public void dailyCleanup() { ... }  // every night at 02:00

    @Schedule(minute = "*/15", hour = "*", persistent = false)
    public void healthCheck() { ... }   // every 15 minutes
}
// Spring equivalent: @Scheduled(cron = "0 0 2 * * *") on any @Component

// @Asynchronous — fire-and-forget or Future-based async
@Stateless
public class ReportService {

    @Asynchronous
    public Future<String> generateReport(Long userId) {
        String report = buildExpensiveReport(userId);
        return new AsyncResult<>(report);  // EJB wrapper, not java.util.concurrent
    }
}

// Caller can block on the result or check completion
Future<String> future = reportService.generateReport(userId);
// ... do other work ...
String report = future.get();  // blocks until ready

// Spring equivalent: @Async returning CompletableFuture<String>

When to Use EJB Today — and When Absolutely Not

Interview Questions