Transaction Management Spring boot | propagation levels | Code Decode | Part 2 | Interview Questions

Transaction propagation concepts (Spring Boot / Code Decode — Part 2)

What this video covers

• Continuation of a Spring Boot transaction management series (Code Decode).
• Builds on previous parts (REQUIRED and demos for REQUIRES_NEW).
• Explains theory and demos for several propagation types and shows practical behavior with examples.

---

Propagation behaviors explained

REQUIRES_NEW

• Always creates a new physical transaction and a new database connection; the outer transaction is suspended while the inner runs.
• Practical effect: outer work is paused until the inner transaction commits or rolls back; inserts in the outer transaction can be delayed/suspended.
• Caution: avoid overusing REQUIRES_NEW because each inner call opens a new DB connection and connections are limited.

NESTED

• If a transaction exists, Spring creates a savepoint so partial rollback is possible.
• If an exception occurs inside the nested region, rollback happens only to the savepoint, not the whole outer transaction (e.g., an address insert could be rolled back while the employee insert remains).
• If no active transaction exists, NESTED behaves like REQUIRED (it creates a new transaction).

MANDATORY

• Requires an existing transaction; it will not start one.

• If none exists, Spring throws an exception:

  “No existing transaction found for transaction marked with propagation mandatory.”

• Demo tip: removing a class-level @Transactional (which had been creating a transaction) demonstrates this exception.

NEVER

• Opposite of MANDATORY: requires that no transaction exists.
• If a transaction exists, Spring throws an exception.

NOT_SUPPORTED

• If a transaction exists, it is suspended; the method runs without a transaction.
• The original transaction resumes after the method completes.
• No exception is thrown—this forces non-transactional execution.

SUPPORTS

• Most flexible: uses an existing transaction if present; otherwise executes non-transactionally.
• It will not create a new transaction.

---

Implementation notes & gotchas

• Class-level @Transactional can take precedence over method-level annotations; be aware when testing propagation behavior. You may need to remove class-level transactional annotations to demonstrate certain cases.
• Demo observations included Hibernate sequence increments and the suspend/resume timing during REQUIRES_NEW.

---

Upcoming topics

• Transaction isolation levels (dirty reads, non-repeatable reads, phantom reads) and prevention strategies — to be covered in a future video.

---

Product mention / promotion

• Brief promo for an app called “Next Level” from Academy For You: coding competitions, professional ratings, partner companies, free app with a waitlist to get early access.

---

Type of content

• Tutorial / demo / interview-prep style explanation (practical demos, code-level behavior and exceptions), aimed at developers learning Spring transaction propagation.

---

Main speaker / sources

• Presenter from the Code Decode channel (video author).
• References: Spring Framework transaction propagation semantics, Hibernate behavior (sequence/DB operations).
• Promo source: Academy For You (Next Level app).