Exception Handling and Troubleshooting

Common Hibernate exceptions fall into two categories: those thrown directly by Hibernate and those propagated from the JDBC layer. In Spring applications, most are translated into Spring's DataAccessException hierarchy.

Most common exceptions

1. LazyInitializationException

Thrown when a lazily loaded association or collection is accessed after the session is closed. The most common Hibernate exception in production:

User user = userRepository.findById(1L).orElseThrow();
// session closed after the method returns (in Open Session in View or service layer)
user.getOrders().size();  // throws LazyInitializationException

Fixes: use JOIN FETCH in the query, @EntityGraph, or load the data within a transaction.

2. EntityNotFoundException / ObjectNotFoundException

Thrown when getReference() / load() is used and the entity does not exist at access time.

3. OptimisticLockException / StaleObjectStateException

Thrown when optimistic locking detects a concurrent modification (the @Version field changed between read and write):

// Concurrent update detected at commit time
@Version
private int version;

Handle by catching and retrying, or surfacing a conflict error to the user.

4. ConstraintViolationException

Wraps a database constraint violation (unique key, not-null, foreign key). Translated to DataIntegrityViolationException by Spring.

5. NonUniqueResultException

Thrown when a query expected to return a single result returns more than one.

6. TransactionRequiredException

Thrown by persist(), merge(), remove(), or flush() when called outside an active transaction.

Spring exception translation

Spring's @Repository annotation + PersistenceExceptionTranslationPostProcessor (auto-configured in Spring Boot) translates Hibernate exceptions into Spring's portable DataAccessException hierarchy:

HibernateException → DataAccessException
  ConstraintViolationException → DataIntegrityViolationException
  LazyInitializationException → InvalidDataAccessApiUsageException
  OptimisticLockException → ObjectOptimisticLockingFailureException

Key interview gotchas

• LazyInitializationException is the #1 issue in production Hibernate apps — the answer is always "fix the query or the transaction boundary," not enabling Open Session in View (which is disabled by default in Spring Boot and is an anti-pattern).
• OptimisticLockException requires a retry strategy — Spring Retry or manual catch-and-retry.
• Never swallow OptimisticLockException silently; data loss can result.
• In Hibernate 6, many exception class names changed slightly — always import from org.hibernate.exception for Hibernate-specific types.

In Hibernate 6, JDBCExceptionReporter has been replaced by a modernized SQL exception handling architecture, but understanding its historical role and the current equivalent is still relevant for interviews.

Historical role (Hibernate 5 and earlier)

JDBCExceptionReporter was a utility class responsible for:

• Logging SQL exceptions that occurred during JDBC execution.
• Extracting meaningful information from SQLException (error code, SQL state, message).
• Serving as the reporting point before Hibernate converted the SQLException into a Hibernate-specific exception.

Current architecture in Hibernate 6

The functionality is now distributed across several components:

• SQLExceptionConverter / SQLExceptionConversionDelegate: converts SQLException into the appropriate JDBCException subclass based on the error code and SQL state, using database-specific knowledge from the Dialect.
• SQLStateConversionDelegate: maps SQL state codes to exception types.
• JDBCException hierarchy: ConstraintViolationException, LockAcquisitionException, JDBCConnectionException, SQLGrammarException, DataException, GenericJDBCException.

How a JDBC exception flows through Hibernate

SQLException (from JDBC driver)
  → SQLExceptionConverter (dialect-aware)
    → JDBCException subclass (e.g., ConstraintViolationException)
      → Spring's PersistenceExceptionTranslationPostProcessor
        → DataAccessException subclass (e.g., DataIntegrityViolationException)

Spring integration

In Spring Boot 3, the @Repository annotation enables automatic exception translation. You rarely need to handle JDBCException directly:

@Repository
public interface ProductRepository extends JpaRepository { }

// ConstraintViolationException is automatically translated to
// DataIntegrityViolationException by Spring

Key interview gotchas

• JDBCExceptionReporter is removed in Hibernate 6 — referencing it in modern code causes a compile error.
• The Dialect participates in exception conversion: the OracleDialect knows Oracle error codes, PostgreSQLDialect knows PostgreSQL error codes, etc.
• Always catch DataAccessException (Spring) rather than HibernateException (Hibernate) in Spring applications for portability.

Performance issues in Hibernate typically fall into a few well-known patterns. Interviewers expect you to name the common root causes and the specific tools and techniques to diagnose and fix them.

1. Identify the N+1 query problem

The most common Hibernate performance issue. Occurs when a query loads N parent entities and then issues N additional queries for each child association:

// Causes N+1 if 'orders' is LAZY:
List customers = em.createQuery("SELECT c FROM Customer c", Customer.class).getResultList();
customers.forEach(c -> c.getOrders().size());  // N extra queries

Diagnose by enabling SQL logging:

spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.orm.jdbc.bind=TRACE

Fix with JOIN FETCH or @EntityGraph:

// Fix with JOIN FETCH
em.createQuery("SELECT c FROM Customer c JOIN FETCH c.orders", Customer.class).getResultList();

// Fix with @EntityGraph in Spring Data
@EntityGraph(attributePaths = {"orders"})
List findAll();

2. Enable Hibernate statistics

spring.jpa.properties.hibernate.generate_statistics=true
logging.level.org.hibernate.stat=DEBUG

StatisticsService reports query counts, cache hits/misses, and entity counts — a fast way to spot abnormal query volumes.

3. Use read-only transactions for queries

@Transactional(readOnly = true)
public List findAll() {
    return productRepository.findAll();
}

This disables Hibernate's dirty-checking flush mechanism, reducing overhead for pure-read operations.

4. Batch processing with StatelessSession

For bulk INSERT/UPDATE operations, use StatelessSession — it bypasses the first-level cache and change tracking:

StatelessSession ss = sf.openStatelessSession();
Transaction tx = ss.beginTransaction();
for (Record r : largeDataset) {
    ss.insert(new Entity(r));
}
tx.commit();
ss.close();

5. Configure JDBC batching

spring.jpa.properties.hibernate.jdbc.batch_size=50
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true

6. Second-level cache

Add Ehcache or Caffeine for frequently read, rarely updated entities:

@Entity
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Category { ... }

Key interview gotchas

• Always diagnose before optimizing — enable SQL logging or statistics first.
• N+1 is the most common answer; know how to detect it (log the query count) and fix it (JOIN FETCH, @EntityGraph, @BatchSize).
• @Transactional(readOnly = true) is a meaningful optimization, not just a documentation hint.
• Avoid spring.jpa.open-in-view=true (disabled in Spring Boot 3 by default) — it masks lazy loading issues.

Hibernate Validator is the reference implementation of the Jakarta Bean Validation specification (jakarta.validation). It validates Java object constraints using annotations, integrating seamlessly with Hibernate ORM and Spring Boot to enforce data integrity at the application layer.

Core constraints (jakarta.validation)

import jakarta.persistence.*;
import jakarta.validation.constraints.*;

@Entity
public class User {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @NotBlank
    @Size(min = 2, max = 50)
    private String name;

    @Email
    @NotNull
    private String email;

    @Min(0) @Max(150)
    private int age;

    @Pattern(regexp = "\\+?[0-9]{10,15}")
    private String phone;
}

Integration with Spring Boot 3

Add the dependency (included transitively with spring-boot-starter-data-jpa):

    org.springframework.boot
    spring-boot-starter-validation

Spring Boot auto-configures Hibernate Validator and integrates it with JPA. Constraints are validated before any persist() or merge() is executed — a ConstraintViolationException is thrown if validation fails.

Validation in controllers (web layer)

@RestController
public class UserController {
    @PostMapping("/users")
    public ResponseEntity create(@Valid @RequestBody UserDto dto) {
        // @Valid triggers bean validation; MethodArgumentNotValidException on failure
    }
}

For exception handling in interviews

Hibernate Validator is not primarily an exception handling tool — it is a constraint enforcement tool. The exception handling aspect is:

• At the persistence layer: javax.validation.ConstraintViolationException (with details of which constraints failed).
• In Spring MVC: MethodArgumentNotValidException (from @Valid on controller parameters), handled via @ControllerAdvice.
• Spring translates ConstraintViolationException from the persistence layer into DataIntegrityViolationException via the @Repository exception translation mechanism.

Key interview gotchas

• Import from jakarta.validation, not javax.validation — the namespace changed with Jakarta EE 9 / Spring Boot 3.
• Hibernate Validator (the library) is the reference implementation of Jakarta Bean Validation (the spec) — they are related but distinct.
• Validation happens at the application layer before the SQL is sent — this is different from database-level constraints, which fire inside the database engine.
• You can validate manually with Validator.validate(object) without going through JPA.

Database connection issues in Hibernate typically surface as JDBCConnectionException or SQLTimeoutException. Robust handling involves a combination of proper connection pool configuration, exception handling, and retry strategies.

1. Proper connection pool configuration

Most connection issues come from poor pool settings. With HikariCP (default in Spring Boot):

spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.connection-timeout=20000
spring.datasource.hikari.idle-timeout=600000
spring.datasource.hikari.max-lifetime=1800000
# Keep connections alive - ping before use
spring.datasource.hikari.keepalive-time=60000
spring.datasource.hikari.connection-test-query=SELECT 1

max-lifetime must be shorter than the database's idle connection timeout to avoid stale connections.

2. Catch and handle connection exceptions

Spring translates Hibernate's connection exceptions into DataAccessException subclasses:

@Service
public class ProductService {
    public Product findById(Long id) {
        try {
            return productRepository.findById(id).orElseThrow();
        } catch (DataAccessResourceFailureException e) {
            // connection failure — log and rethrow or apply fallback
            log.error("Database unavailable", e);
            throw new ServiceUnavailableException("Database temporarily unavailable");
        }
    }
}

3. Retry with Spring Retry

For transient failures (network blip, temporary overload):

@Retryable(
    retryFor = DataAccessResourceFailureException.class,
    maxAttempts = 3,
    backoff = @Backoff(delay = 1000, multiplier = 2)
)
@Transactional
public Product save(Product product) {
    return productRepository.save(product);
}

4. Health checks and monitoring

Spring Boot Actuator exposes /actuator/health which includes a database health indicator:

management.endpoint.health.show-details=always

This checks the DataSource connectivity. Integrate with monitoring tools to alert on connection pool exhaustion.

5. Connection validation

HikariCP validates connections before handing them out by running connection-test-query or using JDBC4 isValid(). This catches stale connections from database restarts or network interruptions without exposing them to application code.

Key interview gotchas

• Hibernate's built-in connection pool is documented as unsuitable for production — always use HikariCP, DBCP2, or c3p0.
• Pool exhaustion (Connection is not available, request timed out) is a connection management issue, not a Hibernate bug — tune pool size and investigate connection leaks.
• Connection leaks occur when sessions/connections are not properly closed — use Spring's transaction management to guarantee cleanup.
• @Transactional plus Spring's transaction manager ensures connections are returned to the pool after each operation, even on exception.

LazyInitializationException is the most common runtime error in Hibernate applications.

Cause: A lazily-loaded association (e.g., @OneToMany with fetch = LAZY) is accessed after the Hibernate Session (or JPA EntityManager) has been closed.

Order order = orderRepository.findById(1L).orElseThrow(); // session closes after this
// ... session is now closed ...
order.getItems().size(); // LazyInitializationException — no active session to load items

Prevention strategies:

1. JOIN FETCH — load the association in the original query:

   @Query("SELECT o FROM Order o JOIN FETCH o.items WHERE o.id = :id")
   Optional findByIdWithItems(@Param("id") Long id);
   

2. @EntityGraph — declarative fetch plan on the repository method:

   @EntityGraph(attributePaths = "items")
   Optional findById(Long id);
   

3. DTOs / Projections — project only needed fields in the query, avoiding lazy associations entirely.

4. @Transactional on service methods — keeps the session open for the duration of the method call, allowing lazy loads within that scope.

What NOT to do:

• Do not enable spring.jpa.open-in-view=true as a fix. It keeps a session open for the entire HTTP request, which masks the problem while causing connection pool exhaustion under load.
• Do not use FetchType.EAGER broadly — it causes unnecessary data loading everywhere the entity is queried.

Root cause mindset: The exception is a symptom of a leaky abstraction — the service or controller is accessing data that should have been fetched at the repository layer. Fix it there.