MiddlewareBox: Tomcat

Showing posts with label Tomcat. Show all posts

15 Jun 2026

🍪 Sessions, Cookies & JSESSIONID Explained - Part 2

Sessions, Cookies & JSESSIONID Explained

Welcome to Part 2 of the Authentication & Identity Security series.
This article explains how applications remember users after successful login.
Designed for Middleware, DevOps, Cloud, and Application Support Engineers.
Includes enterprise examples using WebSphere, Tomcat, JBoss, IBM HTTP Server, NGINX, and Load Balancers.

Introduction
What is a Session?
How WebSphere, JBoss, Tomcat & Docker Store Session Data
What is a Cookie?
What is JSESSIONID?
How Session Management Works
Enterprise Example: WebSphere Session Flow
Sessions Through Load Balancers
Session vs Cookie vs JSESSIONID
Session Security Best Practices
Common Session Issues
Key Takeaways
What’s Next?

Introduction

In Part 1, we learned that authentication verifies a user's identity. After authentication is successful, the next important question is: how does the application remember the same user during future requests?

This is where Sessions, Cookies, and JSESSIONID come into the picture. These components help enterprise applications maintain user identity after login without asking the user to authenticate again on every page.

Key Concept:

Authentication verifies the user once, while session management maintains the user's identity throughout the application journey.

What is a Session?

A session is a server-side mechanism used to store user-specific information after successful authentication.

When a user logs in, the application server creates a unique session for that user. The session may store information such as:

User ID
User role
Login time
Application permissions
User preferences

The session remains active until one of the following events occurs:

User logs out
Session timeout occurs
Application server restarts
Session is invalidated by the application

Middleware View:

In WebSphere, JBoss, and Tomcat, sessions are usually stored in application server memory unless session persistence or replication is configured.

How Do WebSphere, JBoss, Tomcat & Docker Store Session Data?

By default, Java application servers store session data in JVM heap memory. The browser only stores the session identifier (JSESSIONID), while the actual user session data remains on the application server.

Platform	Default Session Storage	High Availability Options
IBM WebSphere	JVM Heap Memory	Memory-to-Memory Replication, Database Persistence
JBoss EAP / WildFly	JVM Heap Memory	Session Replication, Infinispan Cache
Apache Tomcat	JVM Heap Memory	Session Persistence, Redis, Session Replication
Docker Containers	Inside Application JVM/Process	Redis, Database, Sticky Sessions, External Session Store

Docker Session Storage

Browser
   │
JSESSIONID
   │
Docker Container
   │
Tomcat / JBoss / WebSphere Liberty
   │
JVM Heap Memory

Docker itself does not manage user sessions. Sessions are managed by the application running inside the container.

If a container is restarted, redeployed, or scaled down, in-memory sessions may be lost unless external session storage is configured.

Docker Best Practice:

Use Redis, database persistence, sticky sessions, or JWT-based authentication for better scalability and resilience.

A cookie is a small piece of data stored in the user's browser. Applications use cookies to identify users across multiple HTTP requests.

HTTP is stateless by default. This means every request is independent. Without cookies or tokens, the server cannot easily identify whether two requests are coming from the same user.

After successful login, the server sends a cookie to the browser.

Set-Cookie: JSESSIONID=ABC123XYZ789

For every next request, the browser automatically sends this cookie back to the server.

Cookie: JSESSIONID=ABC123XYZ789

What is JSESSIONID?

JSESSIONID is the default session identifier used by Java-based application servers.

It is commonly seen in applications running on:

IBM WebSphere Application Server
WebSphere Liberty
Apache Tomcat
JBoss EAP
WildFly

JSESSIONID does not usually store the full user data. It acts as a reference ID that helps the application server locate the correct server-side session.

JSESSIONID=ABC123XYZ789

Important:

The actual session data is normally stored on the server side. The browser usually stores only the session identifier.

How Session Management Works

User
 │
 ▼
Login Page
 │
 ▼
Authentication Successful
 │
 ▼
Application Server Creates Session
 │
 ▼
JSESSIONID Generated
 │
 ▼
Cookie Sent To Browser
 │
 ▼
Browser Sends Cookie With Every Request
 │
 ▼
Application Server Retrieves Session
 │
 ▼
User Continues Application Access

This process allows the application to remember the authenticated user until logout or session timeout.

Enterprise Example: WebSphere Session Flow

Architecture

User Browser
      │
      ▼
IBM HTTP Server
      │
      ▼
WebSphere Application Server
      │
      ▼
Enterprise Application

Session Flow

User accesses the application login page.
User enters username and password.
WebSphere authenticates the user using LDAP or Active Directory.
WebSphere creates a session in application server memory.
WebSphere generates a JSESSIONID.
Browser receives the JSESSIONID as a cookie.
Browser sends the same cookie in every future request.
WebSphere uses JSESSIONID to locate the user's session.

Example HTTP Response

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/app; HttpOnly; Secure

Example HTTP Request

GET /app/dashboard HTTP/1.1
Host: www.company.com
Cookie: JSESSIONID=ABC123XYZ789

Sessions Through Load Balancers

In enterprise environments, applications often run on multiple servers behind a load balancer.

User Browser
      │
      ▼
NGINX / IBM HTTP Server / F5 / Azure Load Balancer
      │
      ▼
 ┌───────────────┬───────────────┐
 │ WebSphere-01  │ WebSphere-02  │
 └───────────────┴───────────────┘

If a user logs in through WebSphere-01 but the next request goes to WebSphere-02, the session may not be available on WebSphere-02 unless session replication or sticky session is configured.

Common Solutions

Sticky Session: Route the same user to the same backend server.
Session Replication: Copy session data across cluster members.
External Session Store: Store sessions in Redis, database, or distributed cache.

Production Tip:

For stateful Java applications, session affinity is commonly configured at IBM HTTP Server, NGINX, F5, or application server plugin level.

Session vs Cookie vs JSESSIONID

Component	Purpose	Stored In	Example
Session	Stores user-specific data	Application Server	User ID, role, login time
Cookie	Stores small client-side data	Browser	JSESSIONID cookie
JSESSIONID	Identifies the server-side session	Browser cookie or URL	ABC123XYZ789

Session Security Best Practices

Session security is very important because attackers may try to steal or misuse session identifiers.

Use Secure flag so cookies are sent only over HTTPS.
Use HttpOnly flag to reduce JavaScript-based cookie theft.
Use SameSite attribute to reduce CSRF risk.
Regenerate session ID after successful login.
Configure proper session timeout.
Invalidate session during logout.
Avoid exposing JSESSIONID in URLs.

Recommended Cookie Example

Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/; Secure; HttpOnly; SameSite=Lax

Common Session Issues

Middleware and DevOps teams commonly troubleshoot session-related issues in production environments.

Issue	Possible Cause
User logged out unexpectedly	Session timeout or server restart
Session lost after login	Cookie not stored or wrong cookie path
Intermittent logout in cluster	Sticky session or replication issue
JSESSIONID not visible	Application not creating session
Cookie not sent over HTTPS	Secure flag or domain/path mismatch
Login loop	SSO, cookie, or reverse proxy issue

Key Takeaways

Authentication verifies identity.
Sessions maintain user identity after login.
Cookies store identifiers in the browser.
JSESSIONID is the default session identifier for Java applications.
Session affinity and replication are important in clustered environments.
Cookie security flags such as Secure, HttpOnly, and SameSite improve session security.
Session management is critical for WebSphere, JBoss, Tomcat, and enterprise applications.

What’s Next?

Next Article:

Part 3 – Stateful vs Stateless Applications

In the next article, we will understand the difference between stateful and stateless applications and why this concept is important for scaling enterprise applications, APIs, and cloud workloads.

Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com

Pradeep V. (VK)

My Middleware journey began long before cloud, containers, or Prometheus dashboards—deep in traditional enterprise servers, late-night incident calls, SSL headaches, and log-hunting. Over the years, I’ve seen the shift from manual, ticket-driven ops to DevOps, containerization, CI/CD, and cloud. I’m here to share practical lessons from that evolution to help accelerate your journey.

🌐 WebSphere LTPA, Sticky Sessions & Session Replication Explained - Part 9

WebSphere LTPA, Sticky Sessions & Session Replication Explained | MiddlewareBox

Welcome to Part 9 of the Authentication & Identity Security Series. This article explains LTPA (Lightweight Third-Party Authentication), JSESSIONID (Java Session Identifier), Sticky Sessions, Session Replication, and session handling in WebSphere, Tomcat, JBoss and Docker environments.

What is LTPA?
How WebSphere Authentication Works
LTPA vs JSESSIONID
What are Sticky Sessions?
Sticky Sessions vs Session Replication
Session Replication in WebSphere
Session Handling in Tomcat
Session Handling in JBoss
Docker Session Challenges
Common Production Issues
Interview Questions
Best Practices

Common Terms Used in This Article

Abbreviation	Full Form
LTPA	Lightweight Third-Party Authentication
JSESSIONID	Java Session Identifier
IHS	IBM HTTP Server
WAS	WebSphere Application Server
JVM	Java Virtual Machine
HA	High Availability
DR	Disaster Recovery
SSL	Secure Sockets Layer

What is LTPA (Lightweight Third-Party Authentication)?

LTPA (Lightweight Third-Party Authentication) is IBM's authentication token mechanism used by WebSphere Application Server to provide authentication and Single Sign-On across applications.

User Login
    │
    ▼
WebSphere Authentication
    │
    ▼
LTPA Token Generated
    │
    ▼
Browser Stores LTPA Cookie
    │
    ▼
Future Requests Use LTPA Token

LTPA is mainly used for Authentication and Single Sign-On.

How WebSphere Authentication Works

User Browser
      │
      ▼
IBM HTTP Server (IHS)
      │
      ▼
WebSphere Application Server
      │
      ▼
LDAP / Microsoft Entra ID / AD
      │
      ▼
Authentication Success

After successful authentication, WebSphere generates an LTPA token and session information.

LTPA vs JSESSIONID

Feature	LTPA	JSESSIONID
Purpose	Authentication	Session Tracking
Used For	SSO	User Session
Generated After	Login	Session Creation
WebSphere Specific	Yes	No

LTPA identifies who the user is, while JSESSIONID identifies the user's application session.

What are Sticky Sessions?

Sticky Session (Session Affinity) ensures that a user continues to connect to the same application server node.

Load Balancer
      │
      ├── JVM1  ← User Always Routed Here
      │
      └── JVM2

Advantages

Simple configuration
Better performance
No replication overhead

Disadvantages

If JVM crashes, user session may be lost
Not ideal for HA environments

Sticky Sessions vs Session Replication

Feature	Sticky Session	Session Replication
Performance	High	Medium
Failover Support	Limited	Excellent
Complexity	Low	High
HA Support	Partial	Strong

Session Replication in WebSphere

Memory-to-Memory Replication

JVM1
 ↔
JVM2

Database Session Persistence

JVM1
 │
 ▼
Session Database
 │
 ▼
JVM2

If JVM1 fails, JVM2 can continue serving requests using replicated session data.

Session Handling in Apache Tomcat

Browser
   │
JSESSIONID
   │
Tomcat JVM

Tomcat supports clustering using DeltaManager and BackupManager. External session stores such as Redis are commonly used.

Session Handling in JBoss EAP

Browser
   │
JSESSIONID
   │
JBoss Cluster

JBoss commonly uses Infinispan for distributed session replication.

Docker Session Challenges

User
 │
 ▼
Docker Container
 │
 ▼
Tomcat / JBoss / Liberty

If a container restarts, in-memory sessions can be lost.

Common Production Issues

Issue	Cause
Random Logout	Session Timeout
SSO Failure	LTPA Key Mismatch
Session Lost After Restart	In-Memory Session Storage
User Routed To Wrong Node	Load Balancer Affinity Issue
Session Replication Failure	Cluster Misconfiguration

Interview Question

What is the difference between LTPA and JSESSIONID?

LTPA (Lightweight Third-Party Authentication) is used for authentication and Single Sign-On, whereas JSESSIONID (Java Session Identifier) is used for session tracking and maintaining user state.

Best Practices

Use sticky sessions only when failover is not critical.
Enable session replication for HA applications.
Synchronize LTPA keys across WebSphere cells.
Use Redis or database-backed sessions in containers.
Monitor session count and JVM memory usage.
Configure proper session timeout values.
Test failover regularly.

Key Takeaways

LTPA provides WebSphere authentication and SSO.
JSESSIONID tracks user sessions.
Sticky sessions improve performance.
Session replication improves availability.
Docker requires external session management for HA.

What's Next?

Part 10 – Zero Trust Security & Authentication Risks

Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com

Pradeep V. (VK)

⚖️ JWT vs Session vs Cookies Explained - Part 5

JWT vs Session vs Cookies Explained

Welcome to Part 5 of the Authentication & Identity Security series.
This article explains the difference between JWT, Sessions and Cookies.
Designed for Middleware, DevOps, Cloud, API, and Application Support Engineers.
Includes enterprise examples using WebSphere, JBoss, Tomcat, Docker, Azure Entra ID, APIs, and Load Balancers.

Introduction
What is a Cookie?
What is a Session?
What is JWT?
Cookie, Session and JWT Flow
JWT vs Session vs Cookies Comparison
Enterprise Middleware Example
Docker and Cloud Perspective
Azure Entra ID Perspective
Which One Should You Use?
Common Misconceptions
Security Best Practices
Common Production Issues
Key Takeaways
What’s Next?

Introduction

In previous parts, we learned about sessions, cookies, JSESSIONID, stateful applications, stateless applications, and JWT-based authentication.

Now it is important to clearly understand the difference between Cookies, Sessions and JWT. Many engineers confuse these terms and use them interchangeably, but they are different concepts.

Simple Understanding:

A cookie is stored in the browser. A session is stored on the server. A JWT is a signed token usually used for stateless authentication.

A cookie is a small piece of data stored in the user's browser. The server sends a cookie to the browser, and the browser sends it back with future requests.

Cookies are commonly used to store identifiers, preferences, tracking values, and session IDs.

Example Cookie

Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/app; Secure; HttpOnly

Browser Sends Cookie Back

GET /app/dashboard HTTP/1.1
Host: www.company.com
Cookie: JSESSIONID=ABC123XYZ789

Important:

A cookie is only a storage mechanism in the browser. It is not the same as a session.

What is a Session?

A session is server-side storage used to maintain user information after login.

In Java enterprise applications, the session is commonly identified using JSESSIONID.

Session Data Example

Session ID: ABC123XYZ789

Stored on Server:
- userId = pradeep
- role = admin
- loginTime = 10:30 AM
- applicationAccess = policy-portal

The browser does not usually store this full session data. The browser only stores the JSESSIONID cookie. The actual session data remains inside the application server memory or external session store.

Common Platforms

IBM WebSphere Application Server
WebSphere Liberty
Apache Tomcat
JBoss EAP
WildFly

What is JWT?

JWT stands for JSON Web Token. It is a signed token that contains claims about the user or application.

JWT is commonly used in APIs, microservices, mobile applications, Docker-based applications, and cloud-native systems.

JWT Example

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJwcmFkZWVwIiwicm9sZSI6ImFkbWluIn0.
signature

JWT Payload Example

{
  "sub": "pradeep",
  "role": "admin",
  "iss": "https://login.company.com",
  "aud": "api.company.com",
  "exp": 1789459200
}

Important:

JWT payload is encoded, not encrypted by default. Do not store passwords, secrets, or sensitive data inside JWT.

Cookie, Session and JWT Flow

Session + Cookie Flow

User Login
   │
Application Server Authenticates User
   │
Server Creates Session
   │
Server Generates JSESSIONID
   │
Browser Stores JSESSIONID Cookie
   │
Browser Sends Cookie With Every Request
   │
Server Finds Session Using JSESSIONID

JWT Flow

User Login
   │
Authentication Server Validates User
   │
JWT Generated
   │
Client Stores JWT
   │
Client Sends JWT With API Request
   │
API Validates JWT Signature and Expiry
   │
Access Granted

JWT vs Session vs Cookies Comparison

Feature	Cookie	Session	JWT
Basic Meaning	Browser storage mechanism	Server-side user state	Signed authentication token
Stored In	Browser	Application Server / External Store	Client side
Common Example	JSESSIONID cookie	User session in JVM heap	Bearer token
Stateful / Stateless	Storage only	Stateful	Stateless
Server Memory Required	No	Yes, unless externalized	No session memory required
Scaling	Easy	Requires sticky session or replication	Easier horizontal scaling
Best For	Session ID, preferences	Traditional web applications	APIs, mobile apps, microservices
Security Risk	Cookie theft	Session hijacking	Token theft

Enterprise Middleware Example

Traditional WebSphere / JBoss / Tomcat Application

Browser
   │
JSESSIONID Cookie
   │
IBM HTTP Server / NGINX
   │
WebSphere / JBoss / Tomcat
   │
Session Stored in JVM Memory

This architecture is common in enterprise web applications. The application server stores session data and the browser stores only the JSESSIONID.

Common Requirements

Session timeout configuration
Sticky session at load balancer
Session replication in cluster
Secure and HttpOnly cookie flags
Logout session invalidation

Docker and Cloud Perspective

Docker does not automatically make an application stateless. If the application running inside the container stores sessions in JVM memory, it is still stateful.

Stateful Docker Application

Browser
   │
JSESSIONID Cookie
   │
Docker Container
   │
Tomcat / JBoss / WebSphere Liberty
   │
Session Stored in Container JVM Memory

If the container restarts or is replaced, in-memory sessions may be lost.

Better Cloud-Native Options

Use JWT-based stateless authentication
Use Redis as external session store
Use database-backed session persistence
Use short-lived tokens with refresh tokens
Use API Gateway for centralized token validation

Azure Entra ID Perspective

Azure Entra ID commonly issues tokens for modern enterprise applications and APIs.

User
 │
Application
 │
Azure Entra ID Login
 │
Access Token / ID Token
 │
Application or API Access

In this model, Azure Entra ID handles authentication and issues tokens. Applications validate the token before granting access.

Enterprise Use Case:

Azure Entra ID + OAuth2/OIDC + JWT is commonly used for SSO, API authentication, Azure applications, and cloud-native platforms.

Which One Should You Use?

Application Type	Recommended Approach
Traditional WebSphere / JBoss / Tomcat web app	Session + Cookie
REST API	JWT / OAuth2 Access Token
Docker-based application	JWT or Redis-backed session
Single Page Application	OIDC with secure token handling
Enterprise SSO	Azure Entra ID / SAML / OIDC
Legacy Java application	Session-based authentication

Common Misconceptions

Misconception 1: Cookie and Session are Same

This is incorrect. A cookie is stored in the browser. A session is stored on the server.

Misconception 2: JWT Always Replaces Session

JWT is useful for APIs and stateless architectures, but traditional web applications may still use sessions effectively.

Misconception 3: JWT is Always More Secure

JWT security depends on implementation. Poor token storage, long expiry, missing validation, or weak signing keys can create serious risks.

Misconception 4: Docker Makes Applications Stateless

Docker only packages and runs applications. If the application stores sessions in memory, it remains stateful.

Security Best Practices

Cookie Best Practices

Use Secure flag for HTTPS-only transmission.
Use HttpOnly flag to reduce JavaScript access.
Use SameSite attribute to reduce CSRF risk.
Set proper cookie path and domain.

Session Best Practices

Configure proper session timeout.
Invalidate session after logout.
Regenerate session ID after login.
Use session replication or external session store for HA.
Avoid storing unnecessary large objects in session.

JWT Best Practices

Use HTTPS for all token communication.
Keep access tokens short-lived.
Validate signature, expiry, issuer, and audience.
Never store passwords or secrets in JWT payload.
Use refresh tokens carefully.
Rotate signing keys periodically.

Common Production Issues

Issue	Possible Cause
User logged out randomly	Session timeout, server restart, or sticky session issue
Session works on one node but fails on another	No session replication or affinity
JWT gives 401 Unauthorized	Expired token, invalid signature, wrong audience or issuer
Cookie not sent to server	Wrong domain, path, Secure flag, or SameSite setting
High JVM memory usage	Too many sessions or large session objects
Login loop	Cookie, SSO, reverse proxy, or token validation issue

Key Takeaways

A cookie is browser-side storage.
A session stores user data on the server.
JSESSIONID is commonly stored inside a cookie.
JWT is a signed token used for stateless authentication.
Sessions are common in WebSphere, JBoss, and Tomcat applications.
JWT is common in APIs, Docker applications, microservices, and cloud-native systems.
Cookies, sessions, and JWT can all be secure or insecure depending on implementation.

What’s Next?

Next Article:

Part 6 – API Authentication & API Gateway Security

In the next article, we will understand API authentication methods such as API keys, Basic Authentication, JWT, OAuth2, and how API Gateways secure backend services.

Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com

Pradeep V. (VK)

🔄 Stateful vs Stateless Applications Explained - Part 3

Stateful vs Stateless Applications Explained

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.

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.

Key Concept:

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

Middleware View:

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

Cloud View:

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.

Docker Best Practice:

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

Middleware Perspective:

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?

Next Article:

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

Pradeep V. (VK)

2 Nov 2025

🐧 Linux Shell Scripting for Beginners – Complete Tutorial Series.

A 13-part practical shell scripting course for DevOps and Middleware Engineers.

💡 How This Tutorial Series Will Help You

✔ Build a strong foundation in Linux Shell scripting — from basics to automation.
✔ Automate daily Middleware and DevOps tasks: monitoring, backups, and log management.
✔ Write scripts for Middleware platforms like Tomcat, Jenkins, and WebSphere.
✔ Debug, schedule, and manage production-ready shell scripts confidently.
✔ Perfect for Sysadmins, Middleware, and DevOps Engineers upgrading to Cloud roles.

📚 Complete Course Index

🐚 Part 1: What is a Variable?

Learn how variables store data and simplify automation scripts. Foundation of all shell logic.

📥 Part 2: Reading User Input in Shell

Make interactive scripts using read command with Jenkins and Tomcat examples.

🧩 Part 3: Conditional Statements (if, elif, else)

Use decision-making in your scripts with examples checking files, services, and network health.

🔁 Part 4: Loops in Shell (for, while, until)

Automate repetitive DevOps tasks like log cleanup, backups, and status monitoring.

⚙️ Part 5: Functions in Shell (Reusable Scripts)

Write modular, reusable functions — restart Tomcat or back up Jenkins in one click.

📦 Part 6: Arrays & Arguments

Store multiple values, manage user inputs, and process server lists in scripts.

📁 Part 7: File Handling in Shell

Learn how to read, write, append, and handle configuration or log files safely.

💡 Part 8: Debugging & Logging

Find and fix script errors, use logs, and enable debug mode for safe execution.

🕒 Part 9: Scheduling & Automation

Use cron and @reboot jobs to run scripts automatically for health checks or backups.

🎯 Part 10: Middleware Health Monitoring Project

Create a production-ready monitoring script for Tomcat, Jenkins, and NGINX with auto-restart.

🧾 Part 11: Log Management & Rotation

Automate log rotation with logrotate and custom retention scripts for Middleware systems.

💾 Part 12: Backup & Restore Automation Project

Perform automated backup and restore for Jenkins, Tomcat, and WebSphere with rollback support.

⚙️ Part 13: Subshells, Process Control & Parallel Execution

Run multiple jobs in parallel, monitor background processes, and speed up automation workflows.

🚀 Why MiddlewareBox Shell Scripting Series?

✅ Step-by-step, beginner-friendly explanations.
✅ Each topic includes real DevOps & Middleware context.
✅ Examples with Output and Error handling.
✅ Simple language for better understanding.

✨ Start Learning Now → Part 1: What is a Variable?
& build your own scripts from scratch! 💪

Pradeep V. (VK)

⚙️ Shell Scripting for Beginners – Part 13: Subshells, Process Control & Parallel Execution.

Now let's level up and make your shell scripts multitask like a Middleware and DevOps pro.
In this part, you'll learn how to run processes in the background, manage subshells, and execute multiple tasks in parallel for faster automation.

📑 Table of Contents

1️⃣ What is a Subshell?
2️⃣ Running Commands in the Background
3️⃣ Managing Jobs (fg, bg, kill)
4️⃣ Parallel Execution in DevOps
5️⃣ nohup & disown for Long Running Tasks
6️⃣ Real-World Examples (Tomcat, Jenkins, Docker)
🧠 Pro Tips & Troubleshooting
🏁 Summary

1️⃣ What is a Subshell?

A subshell is a new child shell launched from your current shell. It allows running commands in isolation — any variable or environment change inside doesn’t affect the parent shell.

#!/bin/bash
VAR="ParentShell"
( VAR="SubShell"; echo "Inside subshell: $VAR" )
echo "Outside subshell: $VAR"

💬 Output:

Inside subshell: SubShell
Outside subshell: ParentShell

2️⃣ Running Commands in the Background

Add & at the end of a command to run it in the background. This allows your script to keep running while other tasks continue behind the scenes.

#!/bin/bash
echo "Starting Jenkins backup..."
tar -czf /opt/backups/jenkins_backup.tar.gz /var/lib/jenkins & 
echo "Backup started in background (PID: $!)"

💬 Output:

Starting Jenkins backup...
Backup started in background (PID: 2356)

3️⃣ Managing Jobs

When you run background processes, you can manage them using built-in commands:

jobs → List current background jobs
fg %1 → Bring job 1 to foreground
bg %1 → Resume job 1 in background
kill %1 → Kill job 1

#!/bin/bash
long_task() {
  sleep 30 &
}
long_task
jobs

💬 Output:

[1]+ Running sleep 30 &

4️⃣ Parallel Execution in DevOps

Let’s say you want to restart multiple Tomcat servers or back up several apps simultaneously. We can use background jobs with a simple for loop.

#!/bin/bash
servers=("devbox" "testbox" "prodbox")
for srv in "${servers[@]}"; do
  echo "Restarting Tomcat on $srv..."
  ssh $srv "systemctl restart tomcat" &
done

wait  # Wait for all background jobs to finish
echo "✅ All Tomcat servers restarted in parallel!"

💬 Output:

Restarting Tomcat on devbox...
Restarting Tomcat on testbox...
Restarting Tomcat on prodbox...
✅ All Tomcat servers restarted in parallel!

5️⃣ nohup & disown

Sometimes, you need your scripts to survive terminal disconnections — for instance, a long-running Jenkins restore or DB migration.

#!/bin/bash
nohup ./db_migration.sh > /var/log/db_migration.log 2>&1 &
disown
echo "🧠 DB migration running safely in background, even if you close terminal."

💬 Output:

nohup: ignoring input and appending output to 'nohup.out'
🧠 DB migration running safely in background, even if you close terminal.

6️⃣ Real-World DevOps Examples

🧩 Example 1: Parallel Log Collection

#!/bin/bash
servers=("dev" "test" "prod")
for s in "${servers[@]}"; do
  scp $s:/var/log/tomcat/catalina.out /opt/logs/$s.log &
done
wait
echo "✅ Logs collected from all servers."

🧰 Example 2: Monitor Jenkins & Docker in Background

#!/bin/bash
( while true; do pgrep -f jenkins >/dev/null || systemctl restart jenkins; sleep 10; done ) &
( while true; do docker ps | grep -q "webapp" || docker start webapp; sleep 15; done ) &
echo "🩺 Jenkins and Docker monitored in background."

📦 Example 3: Run Multiple CI Jobs Simultaneously

#!/bin/bash
for job in build-test build-stage build-prod; do
  curl -s -X POST "http://jenkins.local/job/$job/build" &
done
wait
echo "✅ All Jenkins build jobs triggered in parallel!"

🧠 Pro Tips & Troubleshooting

🧩 Process Control Best Practices

Use wait to synchronize parallel tasks before continuing.
Log PIDs ($!) to monitor background tasks easily.
Redirect background job output to separate log files using > file 2>&1 &.
For persistent background services, prefer systemd over manual nohup scripts.

⚙️ Debugging Issues

Run ps -ef | grep scriptname to confirm background processes.
Use set -x or bash -x script.sh for detailed command tracing.
Use trap to clean up child processes on script exit.
If parallel SSH commands hang, add -o ConnectTimeout=5 in SSH for safety.

🏁 Summary

✅ Learned to create and manage subshells.
⚙️ Mastered process control using &, jobs, fg, bg, and kill.
🚀 Ran real-world DevOps tasks in parallel — Jenkins builds, Tomcat restarts, Docker checks.
💡 Used nohup and disown for persistent automation tasks.

Pradeep V. (VK)

💾 Shell Scripting for Beginners – Part 12: Backup & Restore Automation Project (DevOps & Middleware Edition)

Here we'll automate backup and restore tasks for real middleware & DevOps systems like Jenkins, Tomcat, WebSphere, MySQL, Docker, and Apache.
Each example includes a working restore script and troubleshooting tips. ⚙️

1️⃣ Jenkins Backup & Restore

#!/bin/bash
JENKINS_HOME="/var/lib/jenkins"
BACKUP_DIR="/opt/backups/jenkins"
mkdir -p $BACKUP_DIR
tar -czf $BACKUP_DIR/jenkins_$(date +%F_%H-%M).tar.gz -C $JENKINS_HOME .
echo "✅ Jenkins backup created in $BACKUP_DIR"

♻️ Restore Jenkins

#!/bin/bash
BACKUP_FILE="/opt/backups/jenkins/jenkins_2025-11-02_02-10.tar.gz"
service jenkins stop
tar -xzf "$BACKUP_FILE" -C /var/lib/jenkins
chown -R jenkins:jenkins /var/lib/jenkins
service jenkins start
echo "♻️ Jenkins restored successfully."

2️⃣ Tomcat Backup & Restore

#!/bin/bash
TOMCAT_HOME="/opt/tomcat"
BACKUP_DIR="/opt/backups/tomcat"
mkdir -p $BACKUP_DIR
tar -czf $BACKUP_DIR/tomcat_$(date +%F).tar.gz $TOMCAT_HOME/webapps $TOMCAT_HOME/conf
echo "📦 Tomcat backup completed."

♻️ Restore Tomcat

#!/bin/bash
BACKUP_FILE="/opt/backups/tomcat/tomcat_2025-11-02.tar.gz"
service tomcat stop
tar -xzf "$BACKUP_FILE" -C /
service tomcat start
echo "♻️ Tomcat restored and restarted."

3️⃣ WebSphere Backup & Restore

#!/bin/bash
WAS_PROFILE="/opt/IBM/WebSphere/AppServer/profiles/AppSrv01"
BACKUP_DIR="/opt/backups/websphere"
mkdir -p $BACKUP_DIR
tar -czf $BACKUP_DIR/was_$(date +%F_%H-%M).tar.gz -C $WAS_PROFILE .
echo "📁 WebSphere configuration backup done."

♻️ Restore WebSphere

#!/bin/bash
BACKUP_FILE="/opt/backups/websphere/was_2025-11-02_03-00.tar.gz"
service was stop
tar -xzf "$BACKUP_FILE" -C /opt/IBM/WebSphere/AppServer/profiles/AppSrv01
service was start
echo "♻️ WebSphere restored successfully."

4️⃣ MySQL Database Backup & Restore

#!/bin/bash
DB="middlewaredb"
USER="root"
PASS="Secret123"
BACKUP_DIR="/opt/backups/mysql"
mkdir -p $BACKUP_DIR
mysqldump -u $USER -p$PASS $DB > $BACKUP_DIR/${DB}_$(date +%F).sql
gzip $BACKUP_DIR/${DB}_$(date +%F).sql
echo "🗄️ MySQL backup completed."

♻️ Restore MySQL

#!/bin/bash
BACKUP_FILE="/opt/backups/mysql/middlewaredb_2025-11-02.sql.gz"
gunzip "$BACKUP_FILE"
mysql -u root -pSecret123 middlewaredb < /opt/backups/mysql/middlewaredb_2025-11-02.sql
echo "✅ Database restored successfully."

5️⃣ Docker Containers Backup & Restore

#!/bin/bash
BACKUP_DIR="/opt/backups/docker"
mkdir -p $BACKUP_DIR
for cid in $(docker ps -q); do
  cname=$(docker inspect --format='{{.Name}}' $cid | cut -d'/' -f2)
  docker export $cid > $BACKUP_DIR/${cname}_$(date +%F).tar
done
echo "🐳 Docker containers exported successfully."

♻️ Restore Docker Container

#!/bin/bash
BACKUP_FILE="/opt/backups/docker/myapp_2025-11-02.tar"
docker import "$BACKUP_FILE" myapp_restored:latest
docker run -d --name myapp_restored myapp_restored:latest
echo "♻️ Docker container restored and running."

6️⃣ Apache Webserver Backup & Restore

#!/bin/bash
BACKUP_DIR="/opt/backups/apache"
mkdir -p $BACKUP_DIR
tar -czf $BACKUP_DIR/apache_$(date +%F).tar.gz /etc/apache2 /var/www/html /etc/ssl
echo "🌐 Apache configuration, website, and SSL backed up."

♻️ Restore Apache

#!/bin/bash
BACKUP_FILE="/opt/backups/apache/apache_2025-11-02.tar.gz"
tar -xzf "$BACKUP_FILE" -C /
service apache2 restart
echo "✅ Apache restored and running."

7️⃣ Automating Backups

Schedule automatic backups using cron so your systems stay protected 24×7.

# Run daily at 2 AM
0 2 * * * /opt/scripts/backup_all.sh >> /var/log/backup_all.log 2>&1

# Run on every reboot
@reboot /opt/scripts/backup_all.sh >> /var/log/backup_boot.log 2>&1

💬 Output:

[CRON] Scheduled backup started…
✅ Jenkins, Tomcat, WebSphere, MySQL, Docker, Apache backed up successfully.

🧠 Pro Tips & Troubleshooting

✅ General Best Practices

Use a dedicated /opt/backups partition or NFS mount to avoid filling system drives.
Compress large backups with gzip or zstd [Developed by Meta] for better space efficiency.
Store daily, weekly, and monthly copies separately (retention policy).
Automate restores in a test environment weekly to ensure recovery works.

⚙️ Troubleshooting Common Issues

❌ Permission Denied: Run backups as sudo or fix ownership using chown.
📦 Disk Full: Use df -h to check space before backup. Add cleanup logic for old files.
🧾 Log Rotation: Add logrotate entry to keep backup logs small and readable.

🏁 Summary

✅ Full backup & restore automation for all major middleware and DevOps tools.
🧩 Scripts are modular, reusable, and easy to integrate in CI/CD pipelines.
⚙️ Cron ensures zero manual intervention for daily protection.

Pradeep V. (VK)

1 Nov 2025

🧾 Shell Scripting for Beginners – Part 11: Log Management & Rotation for Middleware & DevOps Projects

Logs are the heartbeat of your servers 💓 — but if left unmanaged, they'll crash your systems.
In this part, you'll learn how to clean, compress, and rotate logs for Tomcat, Jenkins, Apache, Docker, Kubernetes, and system services using shell scripts and logrotate.

📑 Table of Contents

1️⃣ Log Cleanup Scripts
2️⃣ Apache & Middleware Examples
3️⃣ Docker & K8s Cleanup
4️⃣ logrotate Configuration
5️⃣ How to Run & Test logrotate
🏁 Summary

1️⃣ Log Cleanup Scripts

#!/bin/bash
# Delete logs older than 7 days for Tomcat & Jenkins
find /opt/tomcat/logs/ -type f -name "*.log" -mtime +7 -exec rm -f {} \;
find /var/log/jenkins/ -type f -name "*.log" -mtime +7 -exec rm -f {} \;
echo "🧹 Tomcat & Jenkins logs older than 7 days removed!"

💬 Output:

🧹 Tomcat & Jenkins logs older than 7 days removed!

2️⃣ Apache & Middleware Examples

#!/bin/bash
ARCHIVE="/opt/log_archive/apache"
mkdir -p $ARCHIVE
find /var/log/apache2/ -type f -name "*.log" -mtime +3 -exec gzip {} \;
mv /var/log/apache2/*.gz $ARCHIVE 2>/dev/null
echo "📦 Apache logs compressed and archived in $ARCHIVE"

💬 Output:

📦 Apache logs compressed and archived in /opt/log_archive/apache

3️⃣ Docker & Kubernetes Log Cleanup

#!/bin/bash
echo "🐳 Cleaning Docker & K8s logs..."
docker system prune -af
find /var/log/containers/ -type f -name "*.log" -mtime +5 -exec rm -f {} \;
echo "✅ Docker and Kubernetes logs cleaned!"

💬 Output:

✅ Docker and Kubernetes logs cleaned!

4️⃣ logrotate Configuration

# /etc/logrotate.d/devops-services
/opt/tomcat/logs/*.log
/var/log/apache2/*.log
/var/lib/jenkins/logs/*.log
/var/log/docker/*.log {
    weekly
    rotate 6
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload apache2 2>/dev/null || true
        systemctl restart tomcat 2>/dev/null || true
    endscript
}

💬 Result:

🔁 Logs for Apache, Tomcat, Jenkins, and Docker will rotate weekly and auto-restart services.

5️⃣ How to Run & Test logrotate

Once your config is ready, you can run logrotate manually or let cron handle it.

🧠 Step 1 – Check Syntax of Your Config

sudo logrotate -d /etc/logrotate.d/devops-services

💬 Output:

Reading config file /etc/logrotate.d/devops-services
Handling /opt/tomcat/logs/*.log
Handling /var/log/apache2/*.log
**dry-run mode (no rotation performed)**

⚙️ Step 2 – Run logrotate Manually

sudo logrotate -f /etc/logrotate.d/devops-services

💬 Output:

Rotating logs for Tomcat, Apache, Jenkins...
Compression complete.
Rotation successful ✅

⏰ Step 3 – Schedule via Cron (Daily or Weekly)

# /etc/cron.daily/logrotate
/usr/sbin/logrotate /etc/logrotate.conf

💡 By default, most Linux systems already run logrotate daily using this cron job. You can verify the last run log at /var/lib/logrotate/status.

🏁 Summary

✅ Cleaned and archived logs for Tomcat, Jenkins, Apache, Docker, and K8s.
✅ Created unified logrotate configuration.
✅ Learned to manually test (-d) and force-run (-f) logrotate.
✅ Automated rotation through cron for 24×7 log hygiene.

Pradeep V. (VK)

🎯Shell Scripting for Beginners – Part 10: Middleware Health Monitoring Project (Mixed Example).

This is our final, beginner-friendly project 🎯 — where we'll combine everything you've learned: variables, if-else, loops, functions, logging, and cron automation.
Let's create a simple Middleware Health Monitoring script that checks Tomcat, Jenkins, Docker, MySQL, and SSL expiry.

📑 Table of Contents

1️⃣ Overview
2️⃣ Full Simple Script
3️⃣ Example Output
4️⃣ Automate the Script

1️⃣ Overview

This script uses:

Variables – store names, logs, and domains.
Functions – reusable checks for each service.
If-Else – to decide if a service needs restart.
For loop – to check multiple Docker containers.
While loop – to retry connection.
Logs – write output to a file.

2️⃣ Full Middleware Health Monitoring Script

#!/bin/bash
# MiddlewareBox - Simple Health Monitor

LOG="/var/log/middleware_health.log"
domain="middlewarebox.com"
echo "===== Middleware Health Check =====" >> $LOG
date >> $LOG

# --- Function to check Tomcat ---
check_tomcat() {
  echo "Checking Tomcat..."
  if pgrep -f "org.apache.catalina.startup.Bootstrap" > /dev/null; then
     echo "✅ Tomcat is running" | tee -a $LOG
  else
     echo "🚨 Tomcat is down, restarting..." | tee -a $LOG
     /opt/tomcat/bin/startup.sh
     echo "✅ Tomcat restarted" | tee -a $LOG
  fi
}

# --- Function to check Jenkins ---
check_jenkins() {
  echo "Checking Jenkins..."
  if systemctl is-active --quiet jenkins; then
     echo "✅ Jenkins is active" | tee -a $LOG
  else
     echo "🚨 Jenkins not running, restarting..." | tee -a $LOG
     systemctl restart jenkins
     echo "✅ Jenkins restarted" | tee -a $LOG
  fi
}

# --- Function to check MySQL ---
check_db() {
  echo "Checking MySQL..."
  if mysql -u root -pSecret -e "show databases;" > /dev/null 2>&1; then
     echo "✅ MySQL connection successful" | tee -a $LOG
  else
     echo "🚨 MySQL connection failed" | tee -a $LOG
     echo "Retrying in 5 seconds..."
     sleep 5
     mysql -u root -pSecret -e "show databases;" && echo "✅ MySQL reconnected" | tee -a $LOG
  fi
}

# --- Check Docker Containers using FOR Loop ---
check_docker() {
  echo "Checking Docker containers..."
  for c in nginx webapp db
  do
    status=$(docker inspect -f '{{.State.Status}}' $c 2>/dev/null)
    if [ "$status" != "running" ]; then
      echo "🚨 Container $c is $status, restarting..." | tee -a $LOG
      docker start $c
    else
      echo "✅ Container $c is running" | tee -a $LOG
    fi
  done
}

# --- Check SSL certificate expiry ---
check_ssl() {
  echo "Checking SSL expiry..."
  expiry=$(echo | openssl s_client -servername $domain -connect $domain:443 2>/dev/null | openssl x509 -noout -dates | grep notAfter | cut -d= -f2)
  days_left=$(( ($(date -d "$expiry" +%s) - $(date +%s)) / 86400 ))
  if [ $days_left -le 15 ]; then
    echo "⚠️ SSL expires in $days_left days!" | tee -a $LOG
  else
    echo "✅ SSL valid for $days_left days" | tee -a $LOG
  fi
}

# --- MAIN EXECUTION FLOW ---
check_tomcat
check_jenkins
check_db
check_docker
check_ssl

echo "✅ Health check completed successfully!" | tee -a $LOG
echo "========================================" >> $LOG

💬 Example Output:

✅ Tomcat is running
✅ Jenkins is active
✅ MySQL connection successful
✅ Container nginx is running
✅ SSL valid for 70 days
✅ Health check completed successfully!

3️⃣ Automate the Script

# Run every 30 minutes
*/30 * * * * /opt/scripts/middleware_health.sh >> /var/log/health_cron.log 2>&1

# Run automatically on system reboot
@reboot /opt/scripts/middleware_health.sh >> /var/log/boot_health.log 2>&1

💬 Output (Cron log):

[BOOT] Health check executed
✅ All services healthy

🏁 Summary

✅ Combined all major shell scripting concepts.
✅ Checks Tomcat, Jenkins, Docker, MySQL, and SSL in one file.
✅ Uses if, for, functions, and basic while retry logic.
✅ Can run manually or via cron / reboot automation.

Pradeep V. (VK)

🕒 Shell Scripting for Beginners – Part 9: Scheduling & Automation

In DevOps and Middleware environments, automation isn't complete until it's scheduled.
Here, we master cron, at, @reboot, and Jenkins integration — running scripts automatically for backups, restarts, monitoring, and cleanups.

📑 Table of Contents

1️⃣ Automating with Cron
2️⃣ One-Time Tasks with At
3️⃣ Auto-Execute on System Reboot
4️⃣ Jenkins Scheduler Integration
5️⃣ Real Middleware Automation Examples
6️⃣ Tips & Troubleshooting
🏁 Summary

⏰ 1️⃣ Automating with Cron

cron executes scripts periodically.
Perfect for recurring jobs like backups, cleanup, and health checks.

Example 1: Daily Jenkins Backup at 3 AM

0 3 * * * /opt/scripts/jenkins_backup.sh >> /var/log/jenkins_backup.log 2>&1

💬 Output (log):

[03:00] Jenkins backup started
[03:03] ✅ Jenkins backup completed

Example 2: Weekly Tomcat Log Cleanup

0 2 * * 0 /opt/scripts/cleanup_tomcat_logs.sh >> /var/log/tomcat_cleanup.log 2>&1

💬 Output:

🧹 Deleted old logs from /opt/tomcat/logs
✅ Weekly cleanup done

🕐 2️⃣ One-Time Tasks with At

at executes a job once — ideal for maintenance windows, patches, or urgent restarts.

Example 3: Restart WebSphere at 11:30 PM

echo "/opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1 && sleep 15 && /opt/IBM/WebSphere/AppServer/bin/startServer.sh server1" | at 23:30

💬 Output:

job 17 at Sat Nov 1 23:30:00 2025

Example 4: Run Backup Once in 2 Hours

echo "/opt/scripts/backup_db.sh" | at now + 2 hours

💬 Output:

job 18 at Sat Nov 1 05:30:00 2025

🔄 3️⃣ Auto-Execute on System Reboot

The @reboot keyword in crontab ensures your scripts run every time Linux boots. Perfect for restarting services, mounting drives, or initializing environments.

Example 5: Auto-Start Tomcat After Reboot

@reboot /opt/tomcat/bin/startup.sh >> /var/log/tomcat_reboot.log 2>&1

💬 Output (after reboot):

✅ Tomcat started automatically at boot.

Example 6: Health Check Script at Boot

@reboot /opt/scripts/health_check.sh >> /var/log/health_boot.log 2>&1

💬 Output (log):

[BOOT] Checking WebSphere, Jenkins, NGINX...
✅ All services active.

💡 To verify reboot jobs, check grep CRON /var/log/syslog after restart.

⚙️ 4️⃣ Jenkins Scheduler Integration

In CI/CD, Jenkins provides cron-like scheduling for build pipelines.

Example 7: Daily Jenkins Build at 2 AM

pipeline {
  triggers { cron('H 2 * * *') }
  stages {
    stage('Nightly Build') {
      steps {
        sh '/opt/scripts/build_app.sh'
      }
    }
  }
}

💬 Output:

✅ Jenkins triggered build_app.sh
Build completed successfully.

🧰 5️⃣ Real Middleware & DevOps Automation Examples

Example 8: NGINX Health Monitor Every 10 Minutes

*/10 * * * * /opt/scripts/nginx_health.sh >> /var/log/nginx_monitor.log 2>&1

💬 Output:

[02:40] 🌐 NGINX is active
[02:50] 🚨 NGINX down – restarted automatically.

Example 9: Database Backup Every 6 Hours

0 */6 * * * mysqldump -u root -pSecret middlewaredb > /backup/db_$(date +%F_%H).sql

💬 Output:

✅ Backup completed: db_2025-11-01_06.sql

Example 10: Restart Jenkins After Crash Detection

*/15 * * * * pgrep jenkins >/dev/null || systemctl restart jenkins

💬 Output:

[03:15] 🚨 Jenkins was down, restarted successfully.

Example 11: Auto-Remount Missing Volume

@reboot mount | grep /mnt/backup >/dev/null || mount /dev/sdb1 /mnt/backup

💬 Output:

✅ /mnt/backup auto-mounted on system startup.

🧠 6️⃣ Tips & Troubleshooting

📄 Check logs → grep CRON /var/log/syslog
🔒 Ensure permissions → chmod +x /opt/scripts/*.sh
⚙️ Test reboot jobs manually → sudo run-parts /etc/cron.d/
📧 Use MAILTO in crontab for notifications
🚨 For Jenkins jobs, check /var/lib/jenkins/jobs/*/builds

🏁 Summary

Cron → Schedules recurring jobs
At → Runs one-time tasks
@reboot → Executes scripts on startup
Jenkins → Manages enterprise-level schedules
💡 Combine them to create self-healing, auto-starting Middleware environments.

Pradeep V. (VK)

Menu

15 Jun 2026

Table of Contents

Introduction

What is a Session?

How Do WebSphere, JBoss, Tomcat & Docker Store Session Data?

Docker Session Storage

What is a Cookie?

What is JSESSIONID?

How Session Management Works

Enterprise Example: WebSphere Session Flow

Architecture

Session Flow

Example HTTP Response

Example HTTP Request

Sessions Through Load Balancers

Common Solutions

Session vs Cookie vs JSESSIONID

Session Security Best Practices

Recommended Cookie Example

Common Session Issues

Key Takeaways

What’s Next?

Table of Contents

Common Terms Used in This Article

What is LTPA (Lightweight Third-Party Authentication)?

How WebSphere Authentication Works

LTPA vs JSESSIONID

What are Sticky Sessions?

Advantages

Disadvantages

Sticky Sessions vs Session Replication

Session Replication in WebSphere

Memory-to-Memory Replication

Database Session Persistence

Session Handling in Apache Tomcat

Session Handling in JBoss EAP

Docker Session Challenges

Recommended Solutions

Common Production Issues

Interview Question

Best Practices

Key Takeaways

What's Next?

Table of Contents

Introduction

What is a Cookie?

Example Cookie

Browser Sends Cookie Back

What is a Session?

Session Data Example

Common Platforms

What is JWT?

JWT Example

JWT Payload Example

Cookie, Session and JWT Flow

Session + Cookie Flow

JWT Flow

JWT vs Session vs Cookies Comparison

Enterprise Middleware Example

Traditional WebSphere / JBoss / Tomcat Application

Common Requirements

Docker and Cloud Perspective

Stateful Docker Application

Better Cloud-Native Options

Azure Entra ID Perspective

Which One Should You Use?

Common Misconceptions

Misconception 1: Cookie and Session are Same

Misconception 2: JWT Always Replaces Session

Misconception 3: JWT is Always More Secure

Misconception 4: Docker Makes Applications Stateless

Security Best Practices

Cookie Best Practices

Session Best Practices

JWT Best Practices

Common Production Issues

Key Takeaways

What’s Next?

Table of Contents