<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Transactions on Devops Monk</title><link>https://devops-monk.com/tags/transactions/</link><description>Recent content in Transactions on Devops Monk</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 03 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://devops-monk.com/tags/transactions/index.xml" rel="self" type="application/rss+xml"/><item><title>Transactions: @Transactional, Propagation, and Isolation Levels</title><link>https://devops-monk.com/tutorials/spring-boot/spring-boot-transactions/</link><pubDate>Sun, 03 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/spring-boot/spring-boot-transactions/</guid><description>A transaction ensures that a group of operations either all succeed or all fail — no partial state. Spring&amp;rsquo;s @Transactional makes this simple to use, but the underlying mechanics matter when things go wrong.
How @Transactional Works @Transactional is implemented via AOP (Aspect-Oriented Programming). Spring wraps your bean in a proxy:
Client calls orderService.create() │ ▼ Spring AOP proxy intercepts the call │ ▼ BEGIN TRANSACTION │ ▼ Your actual method body executes (all DB operations share one connection and transaction) │ ├─ No exception → COMMIT │ └─ RuntimeException thrown → ROLLBACK │ ▼ Client receives result (or exception) This means @Transactional only works when:</description></item></channel></rss>