Unravel › Java concepts › Jakarta and other frameworks
EJB session beans and container services
Enterprise JavaBeans are the original Java EE components.
Learn these first
At a glance
A hotel where the management company handles the doors, security passes and billing.
- 1@Stateless beans hold no client state and come from a pool (like a service)@Stateful beans keep state for one client across calls. @Singleton is one shared instance, with @Lock(READ|WRITE) for concurrency.
- 2Every business method is transactional by default: @TransactionAttribute(REQUIRED) (default), REQUIRES_NEW, MANDATORY, NOT_SUPPORTED work like Spring propagationA system exception rolls back; an application exception does not unless @ApplicationException(rollback = true).
- 3Security: @RolesAllowed("admin"), @PermitAll, @DenyAll on methods, enforced by the container using the logged-in principal
- 4Timers: @Schedule(hour = "2", minute = "0", persistent = false) runs a method on a cron-like calendar; TimerService creates programmatic timers@MessageDriven beans consume JMS messages.
- @Schedule timers run on every cluster node unless they are persistent and the server coordinates them; for a single run in a cluster use a singleton timer with persistence or an external lock
- Concurrent access to a @Singleton is container-managed by default: calls are serialised (WRITE lock)
- The container wraps each bean in a proxy (the EJB object) that opens or joins a transaction, checks security, takes an instance from the pool, calls the method and cleans up
@Statelesspublic class InvoiceService { @PersistenceContext EntityManager em; @RolesAllowed("billing") public Invoice create(Order order) { Invoice invoice = new Invoice(order); em.persist(invoice); return invoice; } @Schedule(hour = "2", minute = "0", persistent = false) public void nightlyClose() { em.createQuery("update Invoice i set i.closed = true where i.paid = true").executeUpdate(); }}- line 1 uses Stateless, the core of EJB session beans and container services
- line 13 uses Schedule, the core of EJB session beans and container services
Read the full explanation (about 2 min)
Enterprise JavaBeans are the original Java EE components. The application server manages their transactions, security, pooling, timers and remote access; you write the business logic and annotate it.
A mental model
A hotel where the management company handles the doors, security passes and billing. Staff (beans) only concentrate on the guest request; everything else is provided by the building.
How it works
@Stateless beans hold no client state and come from a pool (like a service). @Stateful beans keep state for one client across calls. @Singleton is one shared instance, with @Lock(READ|WRITE) for concurrency.
Every business method is transactional by default: @TransactionAttribute(REQUIRED) (default), REQUIRES_NEW, MANDATORY, NOT_SUPPORTED work like Spring propagation. A system exception rolls back; an application exception does not unless @ApplicationException(rollback = true).
Security: @RolesAllowed("admin"), @PermitAll, @DenyAll on methods, enforced by the container using the logged-in principal.
Timers: @Schedule(hour = "2", minute = "0", persistent = false) runs a method on a cron-like calendar; TimerService creates programmatic timers. @MessageDriven beans consume JMS messages.
Going deeper
@Schedule timers run on every cluster node unless they are persistent and the server coordinates them; for a single run in a cluster use a singleton timer with persistence or an external lock.
Concurrent access to a @Singleton is container-managed by default: calls are serialised (WRITE lock). Switch to @ConcurrencyManagement(BEAN) or READ locks consciously to allow parallel calls.
Do not start your own threads in an EJB; the container cannot manage the transaction or security context on them. Use @Asynchronous or ManagedExecutorService.
Under the hood
The container wraps each bean in a proxy (the EJB object) that opens or joins a transaction, checks security, takes an instance from the pool, calls the method and cleans up. Remote calls go through RMI/IIOP or similar, which is why @Remote interfaces need serializable arguments.
Common mistakes
- Own threads inside EJBs.
- Assuming schedule timers run once in a cluster.
- Holding state in a stateless bean field.
- Expecting the transaction to roll back on a checked exception.
How Unravel recognises it
When you paste code, Unravel looks for these signs of ejb session beans and container services. Spotting them yourself is a good habit when you read unfamiliar code:
- Annotations:
@Stateless@Stateful@EJB@MessageDriven@TransactionAttribute@TransactionManagement@Schedule@Schedules@Asynchronous@LocalBean@DeclareRoles@PermitAll@DenyAll@Resourceand 3 more - Types:
TimerServiceSessionContextUserTransactionManagedExecutorServiceManagedScheduledExecutorServiceEJBExceptionEJBContext
Part of a learning path
- Jakarta EE and other frameworks · previous: CDI: contexts and dependency injection (Jakarta EE) · next: JAX-RS (Jakarta REST) resources
Related concepts
Frequently asked questions
What is EJB session beans and container services?
Enterprise JavaBeans are the original Java EE components. The application server manages their transactions, security, pooling, timers and remote access; you write the business logic and annotate it.
What are the most common mistakes with EJB session beans and container services?
Own threads inside EJBs. Assuming schedule timers run once in a cluster. Holding state in a stateless bean field. Expecting the transaction to roll back on a checked exception.
How can I see EJB session beans and container services in real code?
Paste your own Java into Unravel and it will point out where ejb session beans and container services appears, explain how it works at the detail level you choose, and draw the flow of the code around it.