Definition
- BeanPostProcessor -- a Spring callback interface with
postProcessBeforeInitialization(runs before @PostConstruct) andpostProcessAfterInitialization(runs after); Spring creates AOP proxies in the after callback. - @EventListener -- an annotation that marks a method as a handler for ApplicationEvent objects; the publisher and listener have no direct dependency on each other.
- @TransactionalEventListener -- a variant that fires only after the transaction commits (AFTER_COMMIT) or rolls back (AFTER_ROLLBACK), preventing side effects for uncommitted transactions.
- SmartLifecycle -- an interface that controls deterministic startup and shutdown ordering via
getPhase(),start(), andstop()methods. - Virtual threads -- lightweight threads from Java 21 (Project Loom) that are cheap to create and block; ideal for I/O-bound work but provide no benefit for CPU-bound tasks.
- Spring Batch -- a framework for processing large volumes of data in chunks with per-chunk transactions, skip/retry fault tolerance, and partitioning for parallelism.
BeanPostProcessor is the HR manager at National Bank of India who adds a security badge to every new employee after hiring. @EventListener is the internal memo system where the settlements department publishes a memo when a batch completes, and the notifications department reacts without either knowing about the other. Spring Batch is the end-of-day settlement run: Rajesh processes 100,000 trades in chunks of 500, commits each chunk, and retries any failed chunk.
Understanding the Concepts
What is BeanPostProcessor and how does Spring use it?
BeanPostProcessor is a callback interface that Spring calls for every bean in the application context. It has two methods: postProcessBeforeInitialization runs before @PostConstruct, and postProcessAfterInitialization runs after. Spring uses this mechanism internally to create AOP proxies -- this is exactly why @Transactional self-invocation fails, because the proxy is wrapped around the bean in the after callback.
At National Bank of India, Rajesh writes a custom BeanPostProcessor to add execution-time metrics to every @Service bean automatically.
package com.bank.config;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.stereotype.Component;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@Component
public class MetricsBeanPostProcessor implements BeanPostProcessor {
private static final Logger log = LoggerFactory.getLogger(MetricsBeanPostProcessor.class);
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName)
throws BeansException {
// runs BEFORE @PostConstruct
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName)
throws BeansException {
// runs AFTER @PostConstruct
// Spring's AutoProxyCreator creates AOP proxies here
if (bean.getClass().getPackageName().startsWith("com.bank.service")) {
log.info("Bean initialized: {} (type: {})", beanName, bean.getClass().getSimpleName());
}
return bean;
}
}
Startup log output:
Bean initialized: accountService (type: AccountService$$SpringCGLIB$$0)
Bean initialized: transferService (type: TransferService$$SpringCGLIB$$0)
Notice the $$SpringCGLIB$$ suffix -- these beans were wrapped in AOP proxies.
How do @EventListener and ApplicationEventPublisher decouple services?
ApplicationEventPublisher lets one bean fire an event, and any @EventListener method in any other bean receives it. The publisher and listener have no direct dependency. This pattern decouples services within the same process.
At National Bank of India, when the settlement batch completes, it publishes a SettlementCompleteEvent. The notification service listens for it and sends a summary email. Neither service knows about the other.
package com.bank.event;
public class SettlementCompleteEvent {
private final int tradeCount;
private final String batchId;
public SettlementCompleteEvent(int tradeCount, String batchId) {
this.tradeCount = tradeCount;
this.batchId = batchId;
}
public int getTradeCount() { return tradeCount; }
public String getBatchId() { return batchId; }
}
package com.bank.service;
import com.bank.event.SettlementCompleteEvent;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.stereotype.Service;
@Service
public class SettlementBatchService {
private final ApplicationEventPublisher publisher;
public SettlementBatchService(ApplicationEventPublisher publisher) {
this.publisher = publisher;
}
public void runBatch(String batchId) {
int count = processAllTrades();
publisher.publishEvent(new SettlementCompleteEvent(count, batchId));
}
private int processAllTrades() {
// process trades and return count
return 15000;
}
}
package com.bank.service;
import com.bank.event.SettlementCompleteEvent;
import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Service;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@Service
public class NotificationService {
private static final Logger log = LoggerFactory.getLogger(NotificationService.class);
@EventListener
public void onSettlementComplete(SettlementCompleteEvent event) {
log.info("Batch {} settled {} trades -- sending summary email",
event.getBatchId(), event.getTradeCount());
// send email to operations team
}
}
Log output:
Batch BATCH-20240115 settled 15000 trades -- sending summary email
What is @TransactionalEventListener and when should you use it?
@TransactionalEventListener fires only after the transaction commits (or rolls back, depending on the phase). This prevents a common bug: sending a notification for a transaction that later rolls back.
At National Bank of India, Rajesh uses AFTER_COMMIT to send transfer confirmation emails only after the database transaction is committed. If the transfer fails and rolls back, no email is sent.
package com.bank.service;
import com.bank.event.TransferCompletedEvent;
import org.springframework.stereotype.Service;
import org.springframework.transaction.event.TransactionalEventListener;
import org.springframework.transaction.event.TransactionPhase;
@Service
public class TransferNotificationListener {
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onTransferCommitted(TransferCompletedEvent event) {
// This ONLY fires after the transaction commits successfully
emailService.send(event.getAccountId(),
"Transfer of " + event.getAmount() + " completed for account " + event.getAccountId());
}
@TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
public void onTransferFailed(TransferCompletedEvent event) {
// This fires only if the transaction rolls back
alertService.notifyOps("Transfer failed for account " + event.getAccountId());
}
}
Scenario 1 -- transfer succeeds:
Transaction commits -> AFTER_COMMIT listener fires -> email sent.
Scenario 2 -- transfer fails:
Transaction rolls back -> AFTER_ROLLBACK listener fires -> ops alerted.
AFTER_COMMIT listener does NOT fire -> no incorrect email sent.
What is SmartLifecycle and how does it control startup/shutdown ordering?
SmartLifecycle controls the startup and shutdown order of background tasks. The getPhase() method returns an integer: lower phase starts first and stops last. This ensures dependencies are ready before dependent components start.
At National Bank of India, Pankaj uses SmartLifecycle to start the database connection check before starting the Kafka consumer, and to stop the Kafka consumer before shutting down the database pool.
package com.bank.config;
import org.springframework.context.SmartLifecycle;
import org.springframework.stereotype.Component;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@Component
public class KafkaConsumerLifecycle implements SmartLifecycle {
private static final Logger log = LoggerFactory.getLogger(KafkaConsumerLifecycle.class);
private boolean running = false;
@Override
public void start() {
log.info("Starting Kafka consumer for trade events");
running = true;
// start consuming from trades topic
}
@Override
public void stop() {
log.info("Stopping Kafka consumer -- draining remaining messages");
running = false;
}
@Override
public boolean isRunning() {
return running;
}
@Override
public int getPhase() {
return 100; // higher phase = starts AFTER lower phases, stops BEFORE them
}
}
Startup order:
Phase 0: Database connection pool initialized
Phase 50: Cache warmer loads exchange rates
Phase 100: Kafka consumer starts (database is ready)
Shutdown order (reverse):
Phase 100: Kafka consumer stops first (no new messages)
Phase 50: Cache cleared
Phase 0: Database pool closed last
How do virtual threads work in Spring Boot and what are the traps?
Virtual threads from Java 21 (Project Loom) are lightweight threads managed by the JVM rather than the operating system. Creating a million virtual threads is cheap. They are ideal for I/O-bound work where threads spend most of their time waiting for network or database responses.
In Spring Boot 3.2+, enabling virtual threads makes all request-handling threads virtual. This means the server can handle thousands of concurrent requests without a large thread pool.
# application.yml -- enable virtual threads (Java 21+)
spring:
threads:
virtual:
enabled: true
The trap is that virtual threads do NOT help CPU-bound work. If the bottleneck is a calculation (like interest computation for 100,000 accounts), virtual threads provide no speedup because they still need a physical CPU core to execute.
The second trap is that the bottleneck shifts to the database connection pool. With platform threads, a pool of 200 threads could saturate a HikariCP pool of 50 connections. With virtual threads, you might have 10,000 concurrent requests, and all of them compete for the same 50 connections. You need semaphores or short timeouts to prevent pool exhaustion.
package com.bank.service;
import org.springframework.stereotype.Service;
import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.concurrent.Semaphore;
@Service
public class AccountQueryService {
// Limit concurrent DB access even with 10,000 virtual threads
private final Semaphore dbSemaphore = new Semaphore(50);
public BigDecimal getBalance(String accountId) throws InterruptedException {
dbSemaphore.acquire();
try {
// I/O-bound: virtual thread parks efficiently during DB query
return accountRepository.findBalanceById(accountId);
} finally {
dbSemaphore.release();
}
}
}
Platform threads (200 Tomcat threads):
Max concurrent requests: 200
Each blocked thread uses ~1MB stack memory
Virtual threads:
Max concurrent requests: 10,000+
Each parked virtual thread uses ~1KB
BUT: all 10,000 compete for 50 DB connections
Solution: semaphore or connection pool timeout
What is Spring Batch chunk processing?
Spring Batch processes large datasets in chunks. A chunk consists of three steps: the ItemReader reads N items from a source (database, file, API), the ItemProcessor transforms each item, and the ItemWriter writes the entire chunk in a single transaction. If the chunk fails, only that chunk rolls back -- previous chunks are already committed.
At National Bank of India, the end-of-day settlement batch processes 100,000 trades in chunks of 500. Each chunk calculates brokerage fees and writes the settlement records.
package com.bank.batch;
import com.bank.model.Trade;
import com.bank.model.Settlement;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.item.ItemProcessor;
import org.springframework.batch.item.database.JdbcCursorItemReader;
import org.springframework.batch.item.database.JdbcBatchItemWriter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;
import java.math.BigDecimal;
import java.math.RoundingMode;
@Configuration
public class SettlementBatchConfig {
@Bean
public Job settlementJob(JobRepository jobRepository, Step settlementStep) {
return new JobBuilder("settlementJob", jobRepository)
.start(settlementStep)
.build();
}
@Bean
public Step settlementStep(JobRepository jobRepository,
PlatformTransactionManager txManager,
JdbcCursorItemReader<Trade> reader,
ItemProcessor<Trade, Settlement> processor,
JdbcBatchItemWriter<Settlement> writer) {
return new StepBuilder("settlementStep", jobRepository)
.<Trade, Settlement>chunk(500, txManager)
.reader(reader)
.processor(processor)
.writer(writer)
.faultTolerant()
.skipLimit(100) // skip up to 100 bad records
.skip(IllegalArgumentException.class)
.retryLimit(3) // retry transient failures 3 times
.retry(org.springframework.dao.TransientDataAccessException.class)
.build();
}
@Bean
public ItemProcessor<Trade, Settlement> processor() {
return trade -> {
BigDecimal brokerage = trade.getAmount()
.multiply(new BigDecimal("0.001"))
.setScale(2, RoundingMode.HALF_UP);
return new Settlement(trade.getId(), trade.getAmount(), brokerage);
};
}
}
Batch execution log:
Chunk 1: Read 500 trades, processed, written. Committed.
Chunk 2: Read 500 trades, processed, written. Committed.
Chunk 3: Trade T-7892 has invalid amount. Skipped. 499 written. Committed.
...
Chunk 200: Read 500 trades, processed, written. Committed.
Job completed: 99,950 settled, 50 skipped, 0 retried.
What are common mistakes with these Spring features?
The most common mistake with @EventListener is publishing an event inside a @Transactional method and expecting the listener to see the committed data. If the listener runs synchronously (the default), it runs inside the same transaction, which has not committed yet. Use @TransactionalEventListener(AFTER_COMMIT) instead.
// WRONG: @EventListener fires BEFORE the transaction commits
@EventListener
public void onTransfer(TransferCompletedEvent event) {
Account a = accountRepo.findById(event.getAccountId()).orElseThrow();
// a.getBalance() might not reflect the transfer yet (uncommitted)
}
// CORRECT: @TransactionalEventListener fires AFTER commit
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onTransfer(TransferCompletedEvent event) {
Account a = accountRepo.findById(event.getAccountId()).orElseThrow();
// a.getBalance() reflects the committed transfer
}
With virtual threads, a common mistake is using synchronized blocks for long operations. Virtual threads that enter a synchronized block pin the carrier thread, negating the benefit. Use ReentrantLock instead.
// WRONG: synchronized pins the carrier thread
public synchronized BigDecimal calculateInterest(String accountId) {
return accountRepository.findBalanceById(accountId); // I/O inside synchronized
}
// CORRECT: ReentrantLock does not pin the carrier thread
private final java.util.concurrent.locks.ReentrantLock lock = new java.util.concurrent.locks.ReentrantLock();
public BigDecimal calculateInterest(String accountId) {
lock.lock();
try {
return accountRepository.findBalanceById(accountId);
} finally {
lock.unlock();
}
}
What should a senior engineer know?
- BeanPostProcessor ordering. Multiple BeanPostProcessors run in order of the @Order annotation. If your custom processor needs to run before Spring's proxy creator, give it a lower order value.
- Event ordering. Multiple @EventListener methods for the same event run in undefined order. Use @Order to control the sequence when order matters.
- Spring Batch partitioning. For large datasets, use a Partitioner to split work across multiple threads or even multiple JVMs. Each partition processes a range of records (e.g., account IDs 1-10000, 10001-20000) independently.
- Virtual thread and ThreadLocal. Virtual threads work with ThreadLocal, but scoped values (preview in Java 21) are more efficient for virtual threads because they avoid the overhead of ThreadLocal cleanup.
- Spring Batch restartability. If a job fails at chunk 150, restarting the job resumes from chunk 150 (not from the beginning) because Spring Batch tracks the read position in the job repository.
What are common interview follow-up questions?
- What is the difference between BeanPostProcessor and BeanFactoryPostProcessor? (BeanPostProcessor modifies bean instances after creation. BeanFactoryPostProcessor modifies bean definitions before any bean is created -- for example, @PropertySource registers property placeholders.)
- Can @EventListener be async? (Yes, annotate the listener method with both @EventListener and @Async. The event fires on a background thread.)
- What happens if a Spring Batch chunk fails and retry is exhausted? (The chunk is skipped if a skip policy is configured. If no skip policy exists, the step fails and the job stops.)
- How do virtual threads handle blocking I/O? (The JVM parks the virtual thread and unmounts it from the carrier thread. The carrier thread is free to run other virtual threads. When the I/O completes, the virtual thread is remounted on an available carrier.)
Visual Overview
BeanPostProcessor Lifecycle
═══════════════════════════
Bean created
│
▼
┌────────────────────────────────┐
│ postProcessBeforeInitialization│
│ (runs BEFORE @PostConstruct) │
└────────────┬───────────────────┘
│
▼
┌────────────────────────────────┐
│ @PostConstruct │
│ (bean's own init method) │
└────────────┬───────────────────┘
│
▼
┌────────────────────────────────┐
│ postProcessAfterInitialization │
│ (AOP proxies created HERE) │
└────────────┬───────────────────┘
│
▼
Bean ready for injection
Spring Batch Chunk Processing
═════════════════════════════
┌──────────┐ ┌──────────────┐ ┌──────────────┐
│ Reader │──►│ Processor │──►│ Writer │
│ read 500 │ │ calculate │ │ batch INSERT │
│ trades │ │ brokerage │ │ 500 rows │
└──────────┘ └──────────────┘ └──────┬───────┘
│
┌─────┴──────┐
│ COMMIT │
│ (per chunk)│
└─────┬──────┘
│
Next chunk...
If chunk fails:
┌──────────┐
│ ROLLBACK │── retry up to 3 times
│ chunk │── then skip bad record
│ only │── previous chunks safe
└──────────┘
Key Takeaway
Spring provides several powerful extension points. BeanPostProcessor modifies beans after initialization -- this is where AOP proxies are created for @Transactional and @Cacheable. At National Bank of India, Rajesh uses a custom BeanPostProcessor to log which service beans were wrapped in proxies at startup. @EventListener decouples services in-process: the batch job publishes a SettlementCompleteEvent, and a separate listener sends the summary email without any dependency between them. @TransactionalEventListener with AFTER_COMMIT fires only after the database transaction commits, ensuring no notification is sent for a transaction that might roll back.
Spring Batch processes large datasets in chunks with per-chunk transactions. The reader fetches N items, the processor transforms each one, and the writer persists the chunk in a single transaction. If a chunk fails, only that chunk rolls back -- previous chunks are already committed. Skip and retry policies handle transient errors and bad records. Virtual threads from Java 21 help the reader's I/O-bound database queries scale cheaply, but the processor's CPU-bound brokerage calculation does not benefit. The key trap with virtual threads is synchronized blocks that pin the carrier thread -- use ReentrantLock instead.
Remember one sentence: BeanPostProcessor creates proxies, @TransactionalEventListener fires after commit, SmartLifecycle orders startup, and Spring Batch processes chunks with skip and retry for fault tolerance.
---