From the javadoc of DefaultTransactionAttribute:

/**
 * The default behavior is as with EJB: rollback on unchecked exception
 * ({@link RuntimeException}), assuming an unexpected outcome outside any
 * business rules. Additionally, we also attempt to rollback on {@link Error} which
 * is clearly an unexpected outcome as well. By contrast, a checked exception is
 * considered a business exception and therefore a regular expected outcome of the
 * transactional business method, i.e. a kind of alternative return value which
 * still allows for regular completion of resource operations.
 * <p>This is largely consistent with TransactionTemplate's default behavior,
 * except that TransactionTemplate also rolls back on undeclared checked exceptions
 * (a corner case). For declarative transactions, we expect checked exceptions to be
 * intentionally declared as business exceptions, leading to a commit by default.
 * @see org.springframework.transaction.support.TransactionTemplate#execute
 */

So likely 1) to allow for easier migration from EJB, and 2) because checked exceptions are assumed to be “regular” behaviour and thus handled explicitly by the business code.

Simple answer:

Checked exceptions are those exceptions which needs to be handled by caller or just in case needs to be thrown by the keyword throws if not able to handle. These exceptions are verified at the compilation time.

But in case of unchecked exceptions, these are Error and RuntimeException exceptions that a caller is not able to handle because this is something that happens at run time.

Hence, by this definition, @Transactional will not handle checked exception as it’s the responsibility of the caller to handle. But the runtime exception is something that can’t be handled by the caller. So, in the case of any database query execution error happened via DAO/Service layer might lead to corruption of data in the database and we must need to rollback as this is sort of a runtime error that can’t be handled by caller gracefully. So, that’s why @Transactional only handles unchecked exceptions.

The @Transactional annotation in Spring rolls back only on unchecked exceptions by default, while checked Exceptions do not trigger a rollback unless explicitly configured. This behaviour is designed to align with the different meanings typically attributed to checked and unchecked exceptions in Java.

Unchecked Exceptions

• Unchecked exceptions usually represent scenarios like null pointer dereferences, illegal arguments, or other logic errors that are outside of the normal flow of control. These are typically programming bugs or unexpected runtime conditions that should not happen during normal operation.

• When such an error occurs, it’s safe to assume that the transactional work up to that point is invalid, so a rollback should happen by default.

Checked Exceptions

• Checked exceptions are intended to signal recoverable issues, such as file not found, database connection failure, or business-related conditions (such as validation errors or user-specific errors).
• Since checked exceptions indicate problems that might be handled gracefully, Spring assumes that the transaction might be recoverable and leaves it up to the developer to decide whether or not a rollback should occur. This gives more flexibility to the developer, as they can choose to retry or handle the exception without rolling back the transaction.

Explicit Rollback for Checked Exceptions

• If you want a rollback to occur for a checked exception, you can explicitly specify this using the rollbackFor attribute of @Transactional.

  @Transactional(rollbackFor = { Exception.class })
  public void <method-name>() throws Exception {
    // logic here
  }
  

• This overrides the default behaviour and forces a rollback even for checked exceptions.

Performance Considerations

• Rolling back a transaction can be resource-intensive (such as database operations like undoing inserts/updates). Rolling back for recoverable or manageable checked exceptions could lead to unnecessary overhead in terms of performance and resource usage.