Two years ago, my friend José Paumard held the talk 'Concurrent and Asynchronous Programming : Loom' at the Geneva Java User Group. In his talk, he mentioned that the Spring team would need to completely redesign their approach to transaction: his reasoning was that the transactions are implemented on top of ThreadLocal object and Loom’s virtual threads break this approach. I was intrigued because though I used Spring transactions a lot via the @Transactional annotation, I never opened thou

Frankel's platform  covers topics related to software development, technology trends, and coding tutorials. Through articles, tutorials, and personal anecdotes, Frankel offers insights into programming languages, development frameworks, and best practices in software engineering. Readers can learn about software design principles, development methodologies, and emerging technologies to enhance their coding skills and build high-quality software applications.

A Java geek

Deep dive into Spring's transaction management implementation, revealing how it relies on ThreadLocal to bind transaction context to threads. Explores the TransactionSynchronizationManager class that stores transaction resources per thread, and contrasts this with Spring's reactive transaction approach using immutable Context objects. Discusses the challenges Spring faces in migrating to virtual threads (Project Loom) while maintaining backward compatibility with existing ThreadLocal-based implementations.

Transactions and ThreadLocal in Spring