Spring Boot Interview: The Event That Lied About Being Saved

Consider the following service:

The application logs:

A. The listener is not executed because the transaction eventually rolls back.

B. The listener executes immediately after publishEvent(), even though the transaction later rolls back.

C. Spring delays the listener until the transaction commits.

D. Spring automatically discards the event when the transaction fails.

🚀 Level up your Java & Spring Boot skills.

Join 8000+ developers and get weekly, no-fluff content featuring practical coding tips, real-world backend insights, and interview questions based on production scenarios.

Founding Member Offer: Lock in founding member price at $50/year (~$4/month) for life. Limited spot left.

So far we have covered 67+ real world based interview questions and will add up to 100 by end of this year.

Testimonials

B. The listener executes immediately after publishEvent(), even though the transaction later rolls back.

A common misconception is:

“Spring events are transaction-aware by default.”

They’re not.

ApplicationEventPublisher.publishEvent() is synchronous by default.

When publishEvent() is called, Spring immediately invokes all matching @EventListener methods.

The listener has no knowledge that the surrounding transaction will later fail.

The email has already been sent.