- Welcome to Part 3 of the Authentication & Identity Security series.
- This article explains the difference between stateful and stateless applications.
- Designed for Middleware, DevOps, Cloud, and Application Support Engineers.
- Includes enterprise examples using WebSphere, JBoss, Tomcat, Docker, JWT (JWT = JSON Web Token), APIs, and Load Balancers.
Table of Contents
- Introduction
- What is State?
- What is a Stateful Application?
- What is a Stateless Application?
- Stateful vs Stateless Flow
- Enterprise Middleware Example
- Docker Example
- Stateful vs Stateless Comparison
- Session vs JWT (JWT = JSON Web Token)
- Where to Use Stateful and Stateless
- Common Production Issues
- Key Takeaways
- What’s Next?
Introduction
In Part 2, we learned how sessions, cookies, and JSESSIONID help applications remember users after login. This leads to an important architecture concept: Stateful vs Stateless Applications.
Understanding this difference is very important for Middleware, DevOps, and Cloud Engineers because it impacts application scaling, load balancing, failover, session management, and cloud migration.
Stateful applications remember user/session information on the server. Stateless applications do not store user state on the server between requests.
What is State?
State means information that the application remembers about a user, request, or transaction.
Examples of state include:
- User login session
- Shopping cart data
- User role and permissions
- Workflow step
- Temporary transaction data
If the server stores this information between requests, the application is usually considered stateful.
What is a Stateful Application?
A stateful application stores user/session data on the server side. The server remembers the user's previous activity.
Example
User Login │ ▼ Application Server Creates Session │ ▼ Session Stored in JVM Memory │ ▼ User Continues Application Access
Traditional Java enterprise applications running on WebSphere, JBoss, or Tomcat are commonly stateful when they use server-side HTTP sessions.
Common Stateful Technologies
- WebSphere HTTP Sessions
- JBoss / Tomcat Sessions
- JSESSIONID-based applications
- Session replication
- Sticky sessions
- Database-backed sessions
If your application depends on JSESSIONID and server-side session memory, it is usually stateful.
What is a Stateless Application?
A stateless application does not store user/session data on the application server between requests. Every request contains enough information for the server to process it independently.
Example
Client Request │ ▼ Authorization: Bearer JWT Token │ ▼ API Server Validates Token │ ▼ Response Sent Back
Modern APIs and microservices commonly use stateless authentication with JWT tokens.
Common Stateless Technologies
- JWT Tokens
- REST APIs
- OAuth2 Access Tokens
- API Gateway Authentication
- Cloud-native applications
Stateless applications are easier to scale because any server can process any request.
Stateful vs Stateless Flow
Stateful Flow
Browser │ Cookie: JSESSIONID │ Load Balancer │ WebSphere / Tomcat / JBoss │ Session Stored in Server Memory
Stateless Flow
Client │ Authorization: Bearer JWT │ API Gateway │ Backend API │ No Server-Side Session Required
Enterprise Middleware Example
Stateful WebSphere Application
Browser │ IBM HTTP Server │ WebSphere Cluster │ Application Session in JVM Heap
In this model, the user session is stored inside the WebSphere JVM. If the next request goes to another cluster member, the user session may be lost unless sticky session or session replication is configured.
Stateful Example Issue
User logs in through WAS01 Next request goes to WAS02 Session not found User gets logged out
Solution
- Enable sticky sessions at IBM HTTP Server or Load Balancer.
- Configure memory-to-memory session replication.
- Use database or external session persistence.
Docker Example
Docker itself does not make an application stateless. The behavior depends on how the application stores state.
Stateful Docker Application
Browser │ Docker Container │ Tomcat / JBoss / WebSphere Liberty │ Session Stored in Container JVM Memory
If the container is restarted or replaced, in-memory sessions may be lost.
Stateless Docker Application
Client │ JWT Token │ Docker Container │ API Service │ No Local Session Storage
A stateless containerized application uses JWT tokens or external systems to avoid storing user sessions inside the container.
For scalable Docker-based applications, avoid storing critical session state only inside container memory. Use Redis, database persistence, or JWT-based stateless authentication.
Stateful vs Stateless Comparison
| Point | Stateful Application | Stateless Application |
|---|---|---|
| Session Storage | Stored on server | Not stored on server |
| Example | JSESSIONID session | JWT token |
| Scaling | More complex | Easier |
| Load Balancer | May require sticky sessions | Any server can handle request |
| Failover | Needs replication/persistence | Easier if token is valid |
| Common Use | Traditional web applications | APIs and microservices |
| Middleware Example | WebSphere / Tomcat session | API with JWT |
Session vs JWT
One of the most common questions in modern application architecture is whether to use traditional sessions or JWT-based authentication.
| Feature | Session-Based Authentication | JWT-Based Authentication |
|---|---|---|
| Architecture Type | Stateful | Stateless |
| User State | Stored on Server | Stored in Token |
| Identifier | JSESSIONID | Bearer Token |
| Storage Location | Application Server | Client Side |
| Scaling | More Complex | Easier |
| Load Balancer Dependency | Often Requires Sticky Sessions | No Sticky Session Required |
| Common Usage | Traditional Web Applications | APIs & Microservices |
Traditional WebSphere, JBoss, and Tomcat applications commonly use sessions. Modern APIs, Docker deployments, cloud-native applications, and microservices commonly use JWT.
Where to Use Stateful and Stateless
| Use Case | Recommended Approach |
|---|---|
| Traditional enterprise web application | Stateful session with sticky session or replication |
| Banking portal with complex workflow | Stateful or hybrid approach |
| REST API | Stateless with JWT/OAuth2 token |
| Microservices | Stateless preferred |
| Docker-based application | Stateless preferred, or external session store |
| Legacy WebSphere application | Stateful session management |
Common Production Issues
Middleware and DevOps teams frequently troubleshoot issues related to stateful and stateless application design.
| Issue | Possible Cause |
|---|---|
| User logged out after failover | Session stored only in one JVM |
| Intermittent session loss | Sticky session not configured |
| Container restart logs out users | Session stored inside container memory |
| API request fails with 401 | JWT token expired or invalid |
| Scaling issue | Stateful design without external session store |
| High JVM memory usage | Too many active sessions stored in heap |
Key Takeaways
- State means information remembered by the application.
- Stateful applications store session data on the server.
- Stateless applications process each request independently.
- JSESSIONID-based applications are usually stateful.
- JWT-based APIs are usually stateless.
- Docker does not automatically make applications stateless.
- Stateless design is preferred for APIs, microservices, and scalable cloud applications.
- Stateful applications need sticky sessions, replication, or external session storage.
What’s Next?
Part 4 – JWT & Token-Based Authentication Explained
In the next article, we will understand JWT, access tokens, refresh tokens, bearer tokens, and how token-based authentication works in modern applications and APIs.
Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog:
MiddlewareBox.com
No comments:
Post a Comment