Hibernate ORM Nightmares: Vanishing Records & Missing Commits in Spring 6

You've been there. You call save() on your repository, check the database, and nothing. The record is gone. Vanished. Or worse, you think you saved data, but the commit never happened, and your users are staring at stale data. After 15 years of debugging Hibernate in Spring Boot applications, I've seen these patterns destroy production deployments. In Spring 6 with Hibernate 6.x, the ORM has gotten smarter, but that intelligence introduces new traps. The persistence context, flush modes, and transaction boundaries are the usual culprits. I once spent three days chasing a bug where records appeared in the database during debugging but vanished in production. The root cause? A missing @Transactional annotation on a service method that triggered a flush before a native query. This article walks through the exact scenarios where Hibernate lies to you, how to diagnose them with Spring Boot 3.2+, and how to prevent data loss. We'll cover dirty checking, flush modes, and the dreaded LazyInitializationException that masks real issues. By the end, you'll know how to interrogate Hibernate's session and make it behave predictably.

The Persistence Context: Your Invisible Buffer

Hibernate's persistence context is like a staging area. When you call save(), the entity isn't written to the database immediately. It sits in the session's first-level cache. This is by design: Hibernate batches writes for performance. But this buffer becomes a nightmare when you expect data to be visible immediately. In Spring 6, the default FlushMode is AUTO, which means Hibernate flushes automatically before any query execution—but only for HQL, JPQL, and Criteria queries. Native SQL queries bypass this check entirely. I've seen teams spend days debugging why a freshly saved record doesn't appear in a native query result. The fix is simple: either use JPQL or call entityManager.flush() before your native query. But here's the trap: if you call flush() and then an exception occurs later, that flush is still committed to the database unless you explicitly roll back. Always pair flush() with proper transaction boundaries.

@Service
public class InvoiceService {
    @PersistenceContext
    private EntityManager entityManager;

    @Transactional
    public Invoice createInvoice(BigDecimal amount) {
        Invoice invoice = new Invoice();
        invoice.setAmount(amount);
        invoice.setStatus("PENDING");
        entityManager.persist(invoice);
        // This native query won't see the new invoice unless we flush
        // entityManager.flush(); // Uncomment to fix
        Query nativeQuery = entityManager.createNativeQuery(
            "SELECT SUM(amount) FROM invoices WHERE status = 'PENDING'");
        BigDecimal total = (BigDecimal) nativeQuery.getSingleResult();
        invoice.setRunningTotal(total);
        return invoice;
    }
}

What the Official Docs Won't Tell You

The official Hibernate documentation says FlushMode.AUTO flushes before 'query execution'. What they don't tell you is that 'query' means HQL, JPQL, or Criteria queries—not native SQL. This distinction has caused countless production outages. Also undocumented: if you use @Transactional on a service method and call another method within the same class (self-invocation), Spring's proxy mechanism bypasses the transaction entirely. The @Transactional annotation is ignored. This means your save() call might not even participate in a transaction. I've debugged systems where developers thought they had transaction boundaries but were actually running without them. Another hidden gem: Hibernate 6.x changed the default flush mode for some operations. In Hibernate 5, certain queries would trigger a flush; in Hibernate 6, they don't. Always verify your Hibernate version's behavior. The docs also gloss over the fact that calling entityManager.clear() after a flush can cause detached entities to become stale, leading to NonUniqueObjectException or stale data updates.

@Service
public class OrderService {
    @Autowired
    private OrderRepository orderRepository;

    @Transactional
    public void processOrder(Order order) {
        orderRepository.save(order);
        // This call bypasses @Transactional because of self-invocation
        this.updateInventory(order); // @Transactional ignored!
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void updateInventory(Order order) {
        // This runs in a new transaction only if called from another bean
    }
}

Dirty Checking: The Silent Update Killer

Hibernate's dirty checking mechanism detects changes to managed entities and flushes them automatically at transaction commit. But this feature can work against you. If you load an entity, modify it, and then call save() again, Hibernate might issue an UPDATE on commit even if you didn't intend to change anything. Worse, if you modify a field that has a @Version annotation for optimistic locking, Hibernate increments the version even if the field didn't actually change. This leads to StaleObjectStateException in high-concurrency scenarios. In Spring 6, the default dirty checking strategy is 'auto', which compares the current state with a snapshot taken at load time. This comparison is expensive for large entities. I've seen systems where dirty checking alone consumed 30% of CPU time. The fix: use @Immutable for read-only entities or @DynamicUpdate to only update changed columns. But beware: @DynamicUpdate can cause issues with inheritance hierarchies. Another trap: if you detach an entity (e.g., by closing the session), modifications are lost. Always merge() detached entities back into the persistence context before saving.

@Entity
@DynamicUpdate // Only updates changed columns
public class Product {
    @Id
    private Long id;
    private String name;
    private BigDecimal price;
    @Version
    private Long version;
}

@Service
public class ProductService {
    @Transactional
    public void updatePrice(Long productId, BigDecimal newPrice) {
        Product product = productRepository.findById(productId).orElseThrow();
        product.setPrice(newPrice);
        // Hibernate detects the change and flushes on commit
        // Without @DynamicUpdate, ALL columns are updated
    }
}

Transaction Boundaries: Where Commits Go to Die

In Spring 6, @Transactional creates a proxy around your method. If an unchecked exception (RuntimeException) is thrown, the transaction rolls back. But checked exceptions (like SQLException) do NOT trigger rollback by default. This is the #1 cause of missing commits. You write a service that catches a checked exception, logs it, and returns normally. The transaction commits—without your data. Why? Because Hibernate might have already flushed the data before the exception, but the commit succeeds because no runtime exception occurred. The fix: always use @Transactional(rollbackFor = Exception.class) to roll back on any exception. Another boundary issue: transaction propagation. If you call a REQUIRES_NEW method from within an existing transaction, the inner transaction commits independently. If the outer transaction rolls back, the inner transaction's changes persist. This can lead to partial updates. I once debugged a payment system where the invoice was saved (inner transaction) but the payment record was rolled back (outer transaction), leaving orphaned invoices. The solution: use NESTED propagation or restructure the logic to avoid nested transactions.

@Service
public class PaymentService {
    @Transactional(rollbackFor = Exception.class)
    public void processPayment(Payment payment) throws SQLException {
        paymentRepository.save(payment);
        // This checked exception won't rollback without rollbackFor
        if (payment.getAmount().compareTo(BigDecimal.ZERO) < 0) {
            throw new SQLException("Negative amount not allowed");
        }
        invoiceService.updateInvoice(payment.getInvoiceId());
    }
}

The LazyInitializationException Masquerade

LazyInitializationException occurs when you access a lazy-loaded association outside of a Hibernate session. But this exception often masks a deeper problem: the session might have already flushed and closed, or the transaction might have completed. In Spring 6, the default behavior is to close the EntityManager at the end of the transaction. If you try to access a lazy collection in a view template after the service method returns, you get this exception. Developers often 'fix' this by adding @Transactional to the controller, which extends the session lifetime—but also extends the transaction, leading to database locks. I've seen production systems where every GET request held a database connection open for seconds because of this. The proper fix: use JOIN FETCH in JPQL to eagerly load required associations, or use Spring's OpenEntityManagerInViewFilter (but beware of performance implications). Another hidden issue: if you use @Transactional(readOnly = true) on a service method, Hibernate might skip dirty checking but still keep the session open. Accessing lazy collections outside the method still fails because the session is closed after the method returns.

@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
    @Query("SELECT o FROM Order o JOIN FETCH o.items WHERE o.id = :id")
    Optional<Order> findByIdWithItems(@Param("id") Long id);
}

@Service
public class OrderService {
    @Transactional(readOnly = true)
    public Order getOrder(Long id) {
        Order order = orderRepository.findByIdWithItems(id);
        // items are already loaded, no LazyInitializationException
        return order;
    }
}

Cascading: The Domino Effect of Data Loss

Cascade types in Hibernate can cause unintended data loss. For example, CascadeType.ALL on a parent entity means that deleting the parent also deletes all children. But if you accidentally remove a child from the collection and then save the parent, Hibernate might delete that child from the database. I've seen this in a SaaS billing system where removing an invoice line item from a list caused the line item to be permanently deleted, even though the developer only intended to unlink it. The fix: use CascadeType.MERGE and CascadeType.PERSIST explicitly, and never use CascadeType.ALL or CascadeType.REMOVE unless you fully understand the implications. Another cascade trap: orphanRemoval = true. If you set this on a OneToMany relationship, removing a child from the collection triggers a DELETE statement. This is useful for composition but dangerous for aggregation. In Spring 6, the default cascade type is NONE, but many developers add CascadeType.ALL without thinking. I always tell my teams: 'Cascade is a promise to delete data. Don't make that promise lightly.'

@Entity
public class Invoice {
    @OneToMany(mappedBy = "invoice", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<LineItem> lineItems = new ArrayList<>();

    public void removeLineItem(LineItem item) {
        lineItems.remove(item); // This triggers DELETE on commit!
        item.setInvoice(null);
    }
}

// Safe approach: use CascadeType.PERSIST and CascadeType.MERGE only
@OneToMany(mappedBy = "invoice", cascade = {CascadeType.PERSIST, CascadeType.MERGE})

Batch Insertion: When Performance Kills Consistency

Hibernate's batch insertion is a performance optimization that groups multiple INSERT statements into a single JDBC batch. But it introduces a nightmare: if one insert in the batch fails, the entire batch is rolled back, and you might not know which record caused the failure. In Spring 6, you can configure batch size with spring.jpa.properties.hibernate.jdbc.batch_size. But if you use IDENTITY generation strategy, Hibernate disables batch insertion entirely because it needs to retrieve the generated ID after each insert. This is a common performance pitfall. The fix: use SEQUENCE or TABLE generation strategies for batchable inserts. Another issue: batch insertion can cause constraint violations to surface later, after the transaction commits, making debugging difficult. I've seen a system where a duplicate email constraint was violated in a batch of 1000 records, but the error message didn't indicate which record caused the issue. The solution: validate data before batch insertion and use smaller batch sizes in production.

@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "user_seq")
    @SequenceGenerator(name = "user_seq", sequenceName = "user_seq", allocationSize = 50)
    private Long id;
    private String email;
}

// application.properties
spring.jpa.properties.hibernate.jdbc.batch_size=30
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true

Debugging Vanishing Records: A Systematic Approach

When records vanish, don't panic. Follow this systematic debug process. First, enable SQL logging: spring.jpa.show-sql=true and spring.jpa.properties.hibernate.format_sql=true. This shows every SQL statement Hibernate executes. If you don't see an INSERT, the record was never flushed. Second, check transaction boundaries: add logging around @Transactional methods to see when they begin and commit. Use TransactionSynchronizationManager.isActualTransactionActive() to verify a transaction is active. Third, inspect the persistence context: call entityManager.contains(entity) to check if the entity is managed. If it returns false, the entity is detached and changes won't be saved. Fourth, check for silent rollbacks: enable spring.jpa.properties.hibernate.generate_statistics=true to see transaction commit and rollback counts. Fifth, verify flush mode: call entityManager.getFlushMode() to ensure it's AUTO. Sixth, check for exception swallowing: add @Transactional(rollbackFor = Exception.class) and log all exceptions. I once used this process to find a bug where a @PreUpdate listener threw an exception that was caught by Hibernate and logged at DEBUG level, causing the entire transaction to roll back without any ERROR log.

@Service
public class DebugService {
    @PersistenceContext
    private EntityManager entityManager;

    public void debugEntity(Long id) {
        User user = entityManager.find(User.class, id);
        System.out.println("Is managed: " + entityManager.contains(user));
        System.out.println("Flush mode: " + entityManager.getFlushMode());
        System.out.println("Transaction active: " +
            TransactionSynchronizationManager.isActualTransactionActive());
        // Check if the entity is dirty
        Metamodel metamodel = entityManager.getMetamodel();
        System.out.println("Entity type: " + metamodel.managedType(User.class));
    }
}