@OneToMany(cascade = CascadeType.ALL)
private List<OrderItem> items;

Java                            Action
Order is saved          ───────→ Parent becomes MANAGED
Cascade triggers        ───────→ Hibernate looks at `items` list
OrderItem is saved      ───────→ Child becomes MANAGED

Order order = new Order();
order.addItem(new OrderItem());
entityManager.persist(order);

Order (NEW)
   ↓
persist()
   ↓
Order (MANAGED)
   ↓
CascadeType.PERSIST triggers
   ↓
OrderItem (NEW) becomes OrderItem (MANAGED)

Order (MANAGED)
   ↓
remove()
   ↓
CascadeType.REMOVE triggers
   ↓
OrderItem (MANAGED) is marked for removal
   ↓
Flush
   ↓
SQL: DELETE FROM order_item WHERE id = ? (Multiple times)
SQL: DELETE FROM order WHERE id = ?

31. Pagination

Pagination means: Don't retrieve thousands or millions of records at once. Retrieve a limited subset.

Suppose your database has 100,000 employees. Instead of selecting all 100,000 rows into memory (which would crash your application), we want to fetch them in manageable chunks:

Page 0 → 20 records
Page 1 → 20 records
Page 2 → 20 records

In Spring Data JPA, this is incredibly easy. You just update your repository method to accept a Pageable object and return a Page:

Page<Employee> findAll(Pageable pageable);

When calling the method, you pass a PageRequest:

PageRequest.of(0, 20);

This means: Give me page index 0 (the first page), with a size of 20 records per page.

32. Sorting + Pagination

It is very rare that you want to paginate unsorted data. A very common real-world pattern is to combine sorting and pagination together.

Here is an example in Spring Data:

PageRequest.of(
    0,
    20,
    Sort.by("salary").descending()
);

Conceptually, this breaks down to:

• Page: 0 (First page)
• Size: 20 records
• Sort: By salary in DESC order (highest paid first)

Why Database-Level Pagination is Critical

Database-level pagination is important because you DO NOT want this to happen:

Database
   ↓
(Returns 100,000 rows)
   ↓
Java Memory
   ↓
(Java discards 99,980 rows to take the first 20)

Instead, the database itself should perform the limiting and pagination. When you use Spring Data's Pageable, Hibernate translates this into highly efficient SQL constraints:

Database
   ↓
ORDER BY (Sorts data)
   ↓
LIMIT / OFFSET (Limits natively in the DB)
   ↓
(Returns exactly 20 rows)
   ↓
Application

33. Page vs Slice

Spring Data provides two main interfaces for handling large data retrieval: Page<T> and Slice<T>.

Page

Provides pagination metadata. Getting total counts usually requires Hibernate to execute an additional, potentially heavy, COUNT query.

• content
• total elements
• total pages
• current page

Slice

Focuses only on whether there is another slice/page available (ideal for "Infinite Scroll" UIs). It avoids the total-count requirement because it doesn't need to know the total pages or elements. For massive datasets, avoiding that extra count query makes a huge performance difference.

34. Complete Real-World Flow

Let's connect everything. Suppose we have a paginated read operation:

@Transactional
public Page<Employee> getEmployees(int page, int size) {
    return employeeRepository.findAll(
        PageRequest.of(page, size, Sort.by("salary").descending())
    );
}

The complete architecture flow looks like this:

HTTP Request
     ↓
Controller
     ↓
Service
     ↓
@Transactional (Boundary opens)
     ↓
Repository
     ↓
Spring Data JPA
     ↓
EntityManager
     ↓
Hibernate (Generates JPQL/SQL)
     ↓
Database (Executes ORDER BY and LIMIT/OFFSET)
     ↓
Result Set
     ↓
Entity objects instantiated
     ↓
Persistence Context / First-Level Cache
     ↓
Service (Receives Page<Employee>)
     ↓
Controller
     ↓
HTTP Response

35. Complete Write Flow

For an update, the code is surprisingly simple:

@Transactional
public void updateSalary(Long id, double salary) {
    Employee employee = entityManager.find(Employee.class, id);
    employee.setSalary(salary);
}

The underlying flow is powerful:

@Transactional
      ↓
Begin transaction
      ↓
find()
      ↓
First-Level Cache / DB
      ↓
Managed Employee returned
      ↓
setSalary() (Modifies Java object)
      ↓
Dirty Checking (Hibernate detects the change)
      ↓
Flush (Hibernate generates UPDATE SQL)
      ↓
Commit (Database saves changes)

Notice you don't need to call entityManager.update(employee); because the entity is already managed.

36. Very Important Interview Flow

If an interviewer asks: "What happens when I change a field of an entity?"

Answer with this exact sequence:

1. The entity is managed by the persistence context.
2. The field is changed in Java memory.
3. Hibernate's persistence context tracks the entity state.
4. Dirty checking detects the change automatically.
5. During flush, Hibernate generates the appropriate UPDATE SQL.
6. The SQL is executed within the active database transaction.
7. The transaction commits, finalizing the save.

37. Most Important Interview Traps

Trap	Reality
"Does save() always immediately execute INSERT?"	No. save() makes the entity managed. Timing of the actual INSERT depends on transaction boundaries, flush mode, and ID generation strategy.
"Is flush the same as commit?"	No. Flush = synchronize persistence context with DB. Commit = finalize transaction.
"Does flush permanently save data?"	Not by itself. A flush sends SQL, but a later rollback can still revert those changes if the transaction fails.
"JPQL uses table names."	No. JPQL uses Entity class names and Entity attributes (fields).
"HQL and JPQL are exactly the same."	No. JPQL is the JPA standard. HQL is Hibernate's specific query language (which includes JPQL but adds extra vendor features).
"Updating a managed entity requires save()."	Not necessarily. Dirty checking detects the change and flushes it automatically at the end of the transaction.
"@Transactional means SQL is executed immediately."	No. It establishes transaction boundaries. Hibernate still controls exactly when the flush happens.

38. Your Hibernate CRUD + Query Mental Map

You should now be able to visualize the whole Spring Boot + Hibernate ecosystem like this:

                 Spring Boot
                     |
                @Transactional
                     |
                EntityManager
                     |
          ┌──────────┼──────────┐
          ↓          ↓          ↓
       persist()   find()    remove()
          |          |          |
          └──────────┼──────────┘
                     ↓
             Persistence Context
                     |
              First-Level Cache
                     |
               Dirty Checking
                     |
                   flush()
                     |
                    SQL
          ┌──────────┼──────────┐
          ↓          ↓          ↓
        INSERT     UPDATE      DELETE
                     |
                 Transaction
                     |
                  commit()
                     |
                  Database

And for querying: Understand how JPQL/HQL operates on entities, and how sorting and pagination push the heavy lifting down to the database to preserve Java memory.

⭐ What you should master for T3

For this Hibernate section, don't just memorize annotations. Be able to confidently explain this exact sequence:

• Entity state
• Persistence Context
• First-Level Cache
• Dirty Checking
• Flush
• SQL
• Transaction
• Commit / Rollback