Spring Boot defaults to application-managed local transactions through @Transactional, but transaction management can also be handled externally through container-managed or distributed transaction coordinators when transactions span multiple resources or systems.
Key Points: • By default, Spring's @Transactional relies on a local PlatformTransactionManager tied to a single resource, like one database. • External or distributed transaction management uses JTA (Java Transaction API) to coordinate a two-phase commit across multiple resources, such as two databases or a database and a message queue. • Application servers like WildFly or WebSphere can provide a container-managed JTA transaction manager. • Distributed transactions add coordination overhead and infrastructure complexity, so many teams prefer the Saga pattern for cross-service consistency instead. • The choice depends on whether true atomicity across multiple resources is required, versus eventual consistency being acceptable.
Example: A legacy application updating both an Oracle database and a JMS queue in the same transaction uses a JTA transaction manager to guarantee both operations commit or roll back together, something a plain local @Transactional couldn't coordinate.
Interview Tip: A concise interview answer is:
"By default Spring Boot manages transactions locally with @Transactional and a single PlatformTransactionManager, but when a transaction spans multiple resources, like two databases, I'd bring in JTA for distributed, container-managed transactions. In a microservices context though, I'd usually favor the Saga pattern over distributed transactions to avoid that coordination overhead."