Spring Transactional Rollback Failure: Avoid Self-Invocation

Many of us think Spring works using annotations. It doesn’t. Spring works using proxies. Annotations are just triggers. The real behavior comes from what Spring wraps around your code. Whenever you use: ✅ @Transactional ✅ @Async ✅ @Cacheable ✅ @Retryable ✅ Spring AOP You are not calling your original method directly. You are calling a proxy object. That proxy decides what should happen before and after your method runs. Example with @Transactional: 1️⃣ Proxy intercepts method call 2️⃣ Transaction starts 3️⃣ Your method executes 4️⃣ Commit / rollback happens Your class never handled the transaction. The proxy did. This also explains many confusing Spring behaviors: ❌ @Transactional not working in self-invocation ❌ Different behavior in tests vs production ❌ Private methods not intercepted ❌ Final methods causing issues ❌ Unexpected performance overhead Most “Spring bugs” are actually proxy misunderstandings. The Real Insight If something behaves differently than expected in Spring, ask: 👉 Am I calling the proxy or the actual object? Once you understand proxies, Spring stops feeling magical. It becomes predictable. And predictable systems are easier to debug. #SpringBoot #Java #BackendEngineering #SpringFramework #AOP #SoftwareArchitecture #Microservices

Why @Transactional doesn’t work on private methods in Spring ? One of the most common pitfalls I see in Spring applications is using @Transactional on private methods and expecting rollback to work. 👉 The problem? Spring manages transactions using proxies. Transactions are applied only when a method is called through the Spring proxy. But private methods: ❌ cannot be overridden ❌ cannot be intercepted by the proxy ❌ @Transactional gets ignored Example ❌ @Service public class UserService { @Transactional public void updateUser(User user) { userRepository.save(user); this.sendEmail(user); // self-invocation → no proxy } @Transactional private void sendEmail(User user) { // Exception here won't trigger rollback } } ✅ Best Practices ✔ Always use @Transactional on public service methods ✔ Avoid self-invocation (this.method()) ✔ Move transactional logic to another service when needed Example fix ✅ @Service @RequiredArgsConstructor public class UserService {  private final UserRepository userRepository;  private final UserService self; // proxy injected  @Transactional  public void updateUser(User user) {   userRepository.save(user);   self.sendEmail(user); // ✅ goes through proxy  }  @Transactional  public void sendEmail(User user) {  } } 👉 Key takeaway: Transactions work only when Spring is in the middle of the call. #SpringBoot #Java #Backend #SoftwareEngineering #Programming #CleanCode

Why Doesn’t Rollback Happen in Self-Invocation with @Transactional? You annotate a method with @Transactional. An exception occurs. You expect a rollback. But the data is still committed. If this happens in Spring Framework, one common reason is self-invocation. What Is Self-Invocation? Self-invocation happens when a method inside a class calls another method of the same class. At first glance, this seems perfectly fine. But here’s the hidden problem. Why Rollback Doesn’t Happen: Spring applies @Transactional using a proxy mechanism. -When a method is called from outside the class, the call goes through Spring’s proxy. -The proxy starts the transaction and manages rollback. However, when a method calls another method inside the same class: -The call happens directly within the object. -It bypasses Spring’s proxy. -Spring never intercepts the call. -The transaction is never started. And if no transaction was started, rollback cannot happen. The Real Reason: Rollback doesn’t fail because of the exception. Rollback fails because Spring never got the chance to manage that internal method call. No proxy interception → No transaction → No rollback. Key Takeaway: @Transactional is not just an annotation. It works only when the method call goes through Spring’s proxy. #Java #SpringBoot #SpringFramework #BackendDevelopment #SoftwareEngineering #Microservices #AOP #Transactional

At 3:30 AM, I stopped debugging the code. The bug wasn’t in my code. At least… that’s what I thought. It was 2:00 AM when I stopped writing the code and started testing it. The Student Feedback System built using Java Spring Boot was ready. JWT (JSON Web Token) authentication was implemented. Database connected. Endpoints responding. Everything looked stable. Until I tested the login flow. Every login attempt failed. No compilation errors. No stack traces. No crashes. Just silent authentication rejection. I checked the controller. Reviewed the service layer. Added logs. Restarted the application. Time passed. 2:45 AM. 3:10 AM. Still broken. And at 3:30 AM, I stopped debugging the code. That’s when I looked beyond the logic. The token expiration was calculated using one timezone, but validation was happening in another. I had generated the expiry using LocalDateTime.now() while validation was comparing it against a UTC-based time reference (similar to Instant.now()). Which meant the token was technically expired the moment it was created. Spring Security wasn’t failing. The backend wasn’t broken. The system was behaving exactly as configured. My assumption was wrong. That night changed how I approach debugging. Most real-world bugs aren’t syntax errors. They’re environment mismatches. Configuration inconsistencies. Context problems. Now before rewriting logic, I check: • System time • Timezone handling • Environment variables • application .properties • Token expiry configuration • Server logs Because sometimes… The difference between a working backend and a broken one is just two clocks speaking different languages. ⸻ #Java #SpringBoot #BackendDevelopment #SoftwareEngineering #Programming #Debugging #Developers #TechLearning #WebDevelopment #GrowthMindset

🚀 What Exactly Is a Bean in Spring? (Simple but Important) Sometimes the simplest questions are the ones we forget to explain clearly. As Spring developers, we often say: “Bean is just an object managed by Spring IoC.” But what does that really mean? In the Spring Framework: A Bean is an object that is: ✔ Created by the Spring IoC container ✔ Managed by the container ✔ Injected using Dependency Injection (DI) ✔ Stored inside the ApplicationContext ✔ Controlled through its lifecycle If you create an object using new, it’s just a normal object. If Spring creates and manages it — it becomes a Bean. Example: @Service public class PaymentService { } Because of @Service, Spring registers this class as a Bean and manages it inside the container. 💡 Why this matters? Understanding Beans properly helps in: Debugging injection issues Avoiding NoUniqueBeanDefinitionException Managing lifecycle correctly Writing clean architecture Sometimes we use Spring daily but forget the fundamentals behind it. Still learning. Still refining basics. #SpringBoot #Java #BackendDevelopment #CleanCode #SoftwareEngineering

What happens when an exception is thrown inside a finally block? • We all learn early that finally always executes • But there’s a dangerous edge case many developers miss Consider this: • An exception occurs in the try block • Control moves to finally • Another exception is thrown inside finally What Java actually does: • The exception from finally overrides the original exception • The original exception is silently lost • Debugging becomes painful because the real cause disappears Why this is risky: • You think cleanup is handled safely • But the real failure gets masked Real-world scenario: • DB query fails → exception thrown • finally tries to close the connection • close() throws another exception • You only see the cleanup failure, not the DB issue Best practices: • Never throw new exceptions from finally • Keep finally simple and safe • Use try-with-resources whenever possible • Log inside finally, don’t propagate Key takeaway: • finally is for cleanup — not logic, not errors, not control flow If this surprised you, you’re not alone. #Java #ExceptionHandling #BackendDevelopment #CleanCode #LearningInPublic

How I Detect Bean Initialization Issues in Spring Boot When facing bean initialization issues in large applications, I follow these steps: ✔️ Check startup logs carefully ✔️ Look for exceptions like BeanCreationException or dependency errors From here we will clearly show which bean is failed and why. ✔️ Identify the exact bean from the stack trace ✔️ Check for circular dependencies If two beans depends on each other in that scenario spring throws an error. ✔️ Verify active profiles I will check is there any missing or wrong profiles configured. ✔️ Ensure proper component scanning and base package structure I will make sure all classes are inside base package of main class annotated with @SpringBootApplication. Most of the time, reading logs properly helps find the root cause quickly. #SpringBoot #Java #BackendDevelopment #Debugging

✅ What is a Spring Bean? A Spring Bean is an object that is created, managed, and maintained by the Spring IoC Container. In simple terms: Any class whose object is managed by Spring is called a Spring Bean. 🔄 How Spring Bean Works 1️⃣ You define a class 2️⃣ You mark it with an annotation like @Component 3️⃣ Spring creates the object 4️⃣ Spring manages its lifecycle 📌 Example: @Component class Engine { } ✔ Spring creates the Engine object ✔ Spring manages it ✔ This object is called a Spring Bean 🧠 Why Spring Beans are Important No manual object creation (new) Loose coupling Easy dependency injection Better maintainability 💡 Simple Line to Remember Spring Bean = Object managed by Spring Container #Spring #SpringBoot #SpringBean #Java #LearningInPublic #BackendDevelopment

𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 (𝗗𝗜) 𝗶𝗻 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁 Many developers use it. Few truly understand it. 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗺𝗲𝗮𝗻𝘀: Spring provides the required objects to your class instead of the class creating them manually. 𝗪𝗶𝘁𝗵𝗼𝘂𝘁 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 ❌ PaymentService service = new PaymentService(); 𝗪𝗶𝘁𝗵 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 ✅ Spring injects the dependency automatically. 🔹 Why DI is Important? Without DI:  • Tight coupling  • Hard to test  • Hard to maintain With DI:  • Loose coupling  • Easy unit testing  • Clean architecture 🔹 Types of Dependency Injection  • 1️⃣ Constructor Injection (Recommended)  • 2️⃣ Setter Injection  • 3️⃣ Field Injection (Not recommended for production) Constructor Injection is best practice because:  • Dependencies become required  • Fields can be final  • Code is easier to test 🔹 When Multiple Beans Exist? Use: @𝗤𝘂𝗮𝗹𝗶𝗳𝗶𝗲𝗿 → Choose a specific bean @𝗣𝗿𝗶𝗺𝗮𝗿𝘆 → Set a default bean Spring gives flexibility, but you must design carefully. 💡 Dependency Injection is not just a feature. It is the foundation of Spring architecture. Master Dependency Injection→ Write cleaner backend code. #SpringBoot #DependencyInjection #Java #BackendDevelopment #CleanArchitecture #SoftwareEngineering #IoC #JavaDeveloper

If your domain is mostly String, int, and BigDecimal, you will likely ship more avoidable bugs. For Java and Spring teams, this is a common trap: primitive obsession (a domain model built from raw primitives). It feels productive because JSON serialization and JPA (Java Persistence API) mapping often just work. The cost shows up later as duplicated validation, unclear intent, and easy-to-swap parameters. Rule of thumb: promote a field to a type when it carries meaning beyond its raw representation. Example: In a checkout flow, you have BigDecimal amount and a String discount. One endpoint treats discount as 10 (10%), another treats it as 0.10. Then a third place rounds differently. Introduce a PercentDiscount value object that accepts one representation, normalizes it, and enforces invariants (range, scale, rounding). Now "10 vs 0.10" is not a recurring debate. It is a constructor rule. When a field should become a type: - You validate the same rule in more than one place (invariants). - You keep normalizing or formatting it (behavior). - It has multiple representations (cents vs dollars, case-insensitive codes). - It is easy to mix up with other fields of the same primitive. - It is part of the ubiquitous language (Money, OrderId, EmailAddress). Trade-off: more types means more boundary plumbing. In Spring, you may need Jackson configuration (for example, @JsonCreator and @JsonValue) and JPA mapping (AttributeConverter or @Embeddable). What is one field in your codebase that is still a String, but should be a type? Inspiration: https://lnkd.in/dEarQAaW #java #ddd #architecture #programming #cleancode #clean #code