{"id":3456,"date":"2026-07-08T04:17:24","date_gmt":"2026-07-08T04:17:24","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/07\/08\/2-transactional-traps-that-catch-even-senior-java-developers-in-interviews\/"},"modified":"2026-07-08T04:17:24","modified_gmt":"2026-07-08T04:17:24","slug":"2-transactional-traps-that-catch-even-senior-java-developers-in-interviews","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/07\/08\/2-transactional-traps-that-catch-even-senior-java-developers-in-interviews\/","title":{"rendered":"2 @Transactional Traps That Catch Even Senior Java Developers in interviews"},"content":{"rendered":"
\n
<\/div>\n
\n
\n

I have 13 years of Java experience. I have also interviewed hundreds of developers at MNCs.<\/p>\n

Two questions about @Transactional<\/code> that catch even senior developers. Try answering before you scroll down.<\/p>\n

\n

<\/a> Q1: If a non-transactional method calls a @Transactional<\/code> method in the same class, does the transaction apply? <\/h3>\n
\n
@Service<\/span> public<\/span> class<\/span> OrderService<\/span> {<\/span> public<\/span> void<\/span> placeOrder<\/span>(<\/span>Order<\/span> order<\/span>)<\/span> {<\/span> this<\/span>.<\/span>saveOrder<\/span>(<\/span>order<\/span>);<\/span> }<\/span> @Transactional<\/span> public<\/span> void<\/span> saveOrder<\/span>(<\/span>Order<\/span> order<\/span>)<\/span> {<\/span> orderRepository<\/span>.<\/span>save<\/span>(<\/span>order<\/span>);<\/span> inventoryRepository<\/span>.<\/span>update<\/span>(<\/span>order<\/span>);<\/span> }<\/span> }<\/span> <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
Answer: No.<\/strong><\/p>\n
Reason, in plain terms:<\/strong> when you add @Transactional<\/code>, Spring does not add the transaction logic inside your class. Instead, it creates a second object that sits in front of your class \u2014 think of it as a wrapper. Other classes that call saveOrder()<\/code> (through @Autowired<\/code>) actually call this wrapper first. The wrapper starts the transaction, then calls your real method, then commits or rolls back.<\/p>\n
This wrapper only exists outside<\/em> your class. So when your own code calls this.saveOrder(order)<\/code>, it skips the wrapper completely and goes straight to the real method. No wrapper means no transaction logic. No rollback if inventoryRepository.update()<\/code> fails.<\/p>\n
This bug never shows up in tests. It only shows up in production, when a failure leaves your data half-updated.<\/p>\n
Fix:<\/strong> call the method from a different class, or inject the wrapper of your own class: <\/p>\n
\n
@Service<\/span> public<\/span> class<\/span> OrderService<\/span> {<\/span> @Autowired<\/span> private<\/span> OrderService<\/span> self<\/span>;<\/span> \/\/ this is the wrapper, not the raw object<\/span> public<\/span> void<\/span> placeOrder<\/span>(<\/span>Order<\/span> order<\/span>)<\/span> {<\/span> self<\/span>.<\/span>saveOrder<\/span>(<\/span>order<\/span>);<\/span> \/\/ now it goes through the wrapper<\/span> }<\/span> @Transactional<\/span> public<\/span> void<\/span> saveOrder<\/span>(<\/span>Order<\/span> order<\/span>)<\/span> {<\/span> orderRepository<\/span>.<\/span>save<\/span>(<\/span>order<\/span>);<\/span> inventoryRepository<\/span>.<\/span>update<\/span>(<\/span>order<\/span>);<\/span> }<\/span> }<\/span> <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
\n
  <\/a> Q2: Does @Transactional<\/code> roll back on every exception? <\/h3>\n
\n
@Transactional<\/span> public<\/span> void<\/span> processRefund<\/span>(<\/span>Order<\/span> order<\/span>)<\/span> throws<\/span> RefundException<\/span> {<\/span> paymentRepository<\/span>.<\/span>markRefunded<\/span>(<\/span>order<\/span>);<\/span> externalRefundService<\/span>.<\/span>notify<\/span>(<\/span>order<\/span>);<\/span> \/\/ throws RefundException<\/span> }<\/span> <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
Answer: No.<\/strong><\/p>\n
Reason:<\/strong> by default, @Transactional<\/code> only rolls back on unchecked exceptions (RuntimeException<\/code> and its subclasses). RefundException<\/code> above is a checked exception. So if it is thrown, Spring lets the transaction commit anyway<\/strong> \u2014 including the markRefunded<\/code> write that happened right before the failure.<\/p>\n
Fix:<\/strong> tell Spring to roll back on any exception, not just unchecked ones: <\/p>\n
\n
@Transactional<\/span>(<\/span>rollbackFor<\/span> =<\/span> Exception<\/span>.<\/span>class<\/span>)<\/span> public<\/span> void<\/span> processRefund<\/span>(<\/span>Order<\/span> order<\/span>)<\/span> throws<\/span> RefundException<\/span> {<\/span> paymentRepository<\/span>.<\/span>markRefunded<\/span>(<\/span>order<\/span>);<\/span> externalRefundService<\/span>.<\/span>notify<\/span>(<\/span>order<\/span>);<\/span> }<\/span> <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
\n
I cover topics like this in more depth in my guide \u2014 Core Java, Java 8 to 21, Multithreading, Spring Boot, Microservices, Design Patterns, and Coding Round Patterns.<\/p>\n
Free sample: https:\/\/drive.google.com\/file\/d\/1u3PQbTY1gLn34UmWG7Cxx4cmdibD2dvU\/view?usp=sharing<\/a><\/p>\n
Full guide: https:\/\/kamaninikhil.gumroad.com\/l\/java-interview-guide<\/a><\/p>\n
Got either one right? Drop it in the comments.<\/p>\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>\n
Fuente: Art\u00edculo original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
I have 13 years of Java experience. I have also interviewed hundreds of developers at MNCs. Two questions about @Transactional that catch even senior developers. Try answering before you scroll down. Q1: If a non-transactional method calls a @Transactional method in the same class, does the transaction apply? @Service public class OrderService { public void […]<\/p>\n","protected":false},"author":1,"featured_media":3455,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[41],"tags":[],"class_list":["post-3456","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devto"],"jetpack_publicize_connections":[],"_links":{"self":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/3456","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/comments?post=3456"}],"version-history":[{"count":0,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/3456\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media\/3455"}],"wp:attachment":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media?parent=3456"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/categories?post=3456"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/tags?post=3456"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}