advanced~3h

Bulk Updates & Batch Processing

Updating or inserting thousands of rows one entity at a time through the persistence context is catastrophically slow at scale — bulk JPQL statements and JDBC batching are the two distinct tools for avoiding that cost, each solving a genuinely different shape of problem.

Learning objectives

Write a bulk JPQL update/delete and explain exactly what it skips compared to entity-by-entity saves.
Explain why an already-loaded entity becomes stale after an unrelated bulk update affecting the same row.
Configure JDBC batching and explain how it differs from a bulk update in what it actually optimizes.

Every write operation in this course so far went through the persistence context, one entity at a time. This chapter covers what happens when you need to update or insert THOUSANDS of rows at once.

📖 Story

Imagine a seasonal sale updating the price on 500,000 products. Here's the catastrophically slow way:

List<Product> products = productRepository.findByCategory("electronics");   // loads 500,000 entities!
for (Product p : products) {
    p.setPrice(p.getPrice().multiply(BigDecimal.valueOf(0.9)));
    // Chapter 4's dirty checking will flush 500,000 individual UPDATE
    // statements, AND hold all 500,000 entities in memory at once.
}

Here's the one-statement fix:

@Modifying
@Query("UPDATE Product p SET p.price = p.price * 0.9 WHERE p.category = :category")
int discountCategory(@Param("category") String category);

This runs as ONE SQL UPDATE, entirely bypassing entity loading and the persistence context — regardless of whether it affects 5 or 5 million rows.

Bulk update/delete — a JPQL statement executed directly against the database, affecting many rows in one statement, WITHOUT loading them as entities. Batch processing (JDBC batching) — grouping multiple INSERT/UPDATE statements into fewer database round-trips, via hibernate.jdbc.batch_size.

Let's see the one critical gotcha with this chapter's discountCategory bulk update.

The persistence context doesn't know a bulk update happened

Product product = entityManager.find(Product.class, 42L);   // now MANAGED, price = $100
productRepository.discountCategory("electronics");            // bulk UPDATE runs, DB price is now $90

System.out.println(product.getPrice());   // still prints $100! Stale — Hibernate has
                                            // no idea the bulk update touched this row.
entityManager.refresh(product);            // NOW it correctly shows $90

JDBC batching — a different tool, for a different shape of problem

spring:
  jpa:
    properties:
      hibernate:
        jdbc:
          batch_size: 50

for (Product p : newProducts) {
    entityManager.persist(p);   // each one is STILL its own INSERT statement —
}                                 // batching just groups every 50 into ONE round-trip,
                                  // instead of one round-trip per insert.

Bulk update = one SQL statement for many rows. Batching = many statements, fewer round-trips. Different problems, different tools.

A bulk JPQL update is translated by Hibernate directly into a single SQL UPDATE statement, with no ResultSet processing, no entity construction, and no persistence-context registration — exactly why it's so much cheaper for large row counts, and exactly why the persistence context has no way to know it happened, as this chapter's refresh() example shows.

This chapter's exact seasonal-sale price update is the textbook bulk-update case.
A nightly batch job inserting hundreds of thousands of records relies on JDBC batching combined with Chapter 4's periodic flush-and-clear pattern.

Use a bulk update, like this chapter's discountCategory, for any "change this field across many rows" operation.
Always clear or refresh the persistence context after a bulk update if an already-managed entity in the SAME unit of work could be affected — exactly this chapter's stale-price example.
Configure hibernate.jdbc.batch_size for any loop inserting/updating many individual entities.

⚠️ Why this keeps happening

A bulk update's persistence-context-bypassing behavior is invisible until it specifically collides with an already-loaded entity in the same transaction.

Not clearing/refreshing the persistence context after a bulk update — exactly this chapter's product.getPrice() still showing the stale $100.
Looping and calling save() individually for a genuinely bulk operation, instead of this chapter's one-statement fix.
Assuming JDBC batching gives you the same performance profile as a bulk update — batching still executes one statement per row; it only reduces round-trips.

Bulk updates are dramatically faster than entity-by-entity saves for large row counts — exactly this chapter's 500,000-product example, since it skips entity loading, hydration, and dirty checking entirely.

Bulk updates built from unvalidated user input carry the same injection risk as any JPQL — and a bulk operation affecting many rows is a HIGHER-blast-radius target than a single-row operation.

Log and monitor row counts actually affected by production bulk operations — a bulk update affecting dramatically more or fewer rows than expected signals a WHERE clause bug.

Test bulk update/delete WHERE clauses very carefully against staging with production-shaped data before running in production.

Build this chapter's exact discountCategory bulk update and confirm (via SQL logging) it executes as ONE statement, not one per row.
Reproduce this chapter's stale-entity scenario — load an entity, run a bulk update affecting that row, and confirm the in-memory entity is stale until refreshed.
Configure hibernate.jdbc.batch_size and insert 1,000 entities in a loop, comparing round-trips with and without batching.

✓ Quick recap

A bulk JPQL update/delete executes as one statement affecting many rows, entirely bypassing entity loading — exactly this chapter's discountCategory example.
The persistence context has no awareness a bulk update happened — an already-loaded entity for an affected row becomes stale.
JDBC batching reduces round-trips for many individual saves, but still executes one statement per row — a different tool.

Want a visual for this concept?

Generate a diagram tailored to “Bulk Updates & Batch Processing” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.

Practice quiz

Next Step

Continue to Stored Procedures with JPA →← Back to all Spring Data JPA & Hibernate Mastery chapters