@OneToMany relationship in Spring Boot - Performance & Optimization

Performance: @OneToMany relationship

MEDIUM IMPACT

This affects server response time and client rendering speed due to data loading and serialization of related entities.

Fetching parent entity with many child entities

Spring Boot

@Entity
public class Parent {
  @OneToMany(fetch = FetchType.LAZY)
  private List<Child> children;
}

Lazy loading fetches children only when needed, reducing initial data load and speeding response.

📈 Performance GainReduces initial payload size, improves LCP by loading less data upfront

Fetching parent entity with many child entities

Spring Boot

@Entity
public class Parent {
  @OneToMany(fetch = FetchType.EAGER)
  private List<Child> children;
}

Eager fetching loads all children immediately, causing large data transfer and slow response.

📉 Performance CostBlocks server response longer, increases payload size, delays LCP

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Eager @OneToMany loading	N/A (server-side)	N/A	Large JSON payload delays rendering	[X] Bad
Lazy @OneToMany loading with pagination	N/A (server-side)	N/A	Smaller payload improves rendering speed	[OK] Good

Rendering Pipeline

The server fetches parent and child entities, serializes them to JSON, sends to client, which then renders the data. Large @OneToMany collections increase serialization and transfer time.

→Data Fetching

→Serialization

→Network Transfer

→Client Rendering

⚠️ BottleneckSerialization and network transfer of large collections

Core Web Vital Affected

LCP

This affects server response time and client rendering speed due to data loading and serialization of related entities.

Optimization Tips

1Avoid FetchType.EAGER on large @OneToMany collections to prevent slow page loads.

2Use FetchType.LAZY and load child entities only when needed.

3Implement pagination or DTO projections to limit data size sent to clients.

Performance Quiz - 3 Questions

What is the main performance issue with using FetchType.EAGER on a @OneToMany relationship?

A It delays loading related entities until explicitly accessed.

B It loads all related entities immediately, increasing payload size and slowing response.

C It caches entities on the client side.

D It compresses data to reduce network usage.

DevTools: Network

How to check: Open DevTools, go to Network tab, reload page, inspect JSON response size and load time for API calls fetching @OneToMany data.

What to look for: Look for large payload sizes and long transfer times indicating heavy eager loading.

Practice

1. What does the @OneToMany annotation represent in Spring Boot JPA?

easy

A. A relationship where one entity is linked to many entities

B. A relationship where many entities are linked to one entity

C. A way to delete entities automatically

D. A method to fetch data lazily

Solution

1. Step 1: Understand the meaning of @OneToMany

   The annotation defines a connection where one object relates to multiple objects, like one author having many books.

2. Step 2: Differentiate from other relationships

   @ManyToOne is the opposite, linking many entities to one. @OneToMany specifically means one to many.

3. Final Answer:

   A relationship where one entity is linked to many entities -> Option A

4. Quick Check:

   @OneToMany = one to many link [OK]

Hint: Think 'one' object owns 'many' related objects [OK]

Common Mistakes:

• Confusing @OneToMany with @ManyToOne
• Thinking it deletes entities automatically
• Assuming it controls fetch type only

2. Which of the following is the correct way to declare a @OneToMany relationship in an entity class?

easy

A. @OneToMany(mappedBy = "parent") private List<Child> children;

B. @OneToMany private Child child;

C. @OneToMany(mappedBy = "children") private Child parent;

D. @OneToMany private Map childrenMap;

Solution

1. Step 1: Check the collection type for @OneToMany

   @OneToMany requires a collection like List or Set to hold multiple related entities, so List<Child> is correct.

2. Step 2: Verify the mappedBy attribute usage

   mappedBy should point to the field name in the Child entity that owns the relationship, here "parent" is correct.

3. Final Answer:

   @OneToMany(mappedBy = "parent") private List<Child> children; -> Option A

4. Quick Check:

   Use collection + mappedBy for correct syntax [OK]

Hint: Use a collection and mappedBy to link entities [OK]

Common Mistakes:

• Using single object instead of collection
• Wrong mappedBy value
• Using Map instead of List or Set

3. Given the following code snippet, what will be the output when fetching a Department entity?

@Entity
public class Department {
  @Id
  private Long id;

  @OneToMany(mappedBy = "department", fetch = FetchType.EAGER)
  private List<Employee> employees;

  // getters and setters
}

Assuming the department has 3 employees, what happens when you load the department?

medium

A. Only one employee is loaded due to default limit

B. The department loads without employees until accessed

C. The department loads with all 3 employees immediately

D. An error occurs because fetch type is invalid

Solution

1. Step 1: Understand fetch type EAGER

   FetchType.EAGER means related entities are loaded immediately with the main entity.

2. Step 2: Apply to the employees list

   Since employees are marked EAGER, all 3 employees will be loaded when the department is fetched.

3. Final Answer:

   The department loads with all 3 employees immediately -> Option C

4. Quick Check:

   FetchType.EAGER loads related entities immediately [OK]

Hint: EAGER fetch loads all related data immediately [OK]

Common Mistakes:

• Confusing EAGER with LAZY fetch
• Assuming default fetch loads lazily
• Expecting errors from fetch type

4. Identify the error in this @OneToMany mapping:

@Entity
public class Order {
  @Id
  private Long id;

  @OneToMany
  private List<Item> items;

  // getters and setters
}

Why might this cause issues when saving an Order with Items?

medium

A. List<Item> should be Set<Item> for @OneToMany

B. Missing mappedBy causes owning side confusion

C. The @Id annotation is missing

D. Items should be annotated with @ManyToMany

Solution

1. Step 1: Check ownership in bidirectional @OneToMany

   Without mappedBy, JPA doesn't know which side owns the relationship, causing extra join tables or errors.

2. Step 2: Understand impact on saving

   Without ownership, saving Order and Items may not link properly, causing data inconsistency.

3. Final Answer:

   Missing mappedBy causes owning side confusion -> Option B

4. Quick Check:

   mappedBy defines owner, missing it causes issues [OK]

Hint: Always set mappedBy on non-owning side [OK]

Common Mistakes:

• Omitting mappedBy in bidirectional relationships
• Confusing collection types for @OneToMany
• Misusing @ManyToMany instead of @OneToMany

5. You want to delete a Category and all its related Product entities automatically. Which @OneToMany configuration achieves this behavior?

hard

A. @OneToMany(cascade = CascadeType.PERSIST) private List<Product> products;

B. @OneToMany(mappedBy = "category") private List<Product> products;

C. @OneToMany(fetch = FetchType.LAZY) private List<Product> products;

D. @OneToMany(mappedBy = "category", cascade = CascadeType.ALL, orphanRemoval = true) private List<Product> products;

Solution

1. Step 1: Understand cascade and orphanRemoval

   CascadeType.ALL applies all operations including delete to related entities. orphanRemoval=true removes child entities if removed from parent.

2. Step 2: Apply to deleting Category

   With cascade ALL and orphanRemoval, deleting Category deletes all linked Products automatically.

3. Final Answer:

   @OneToMany(mappedBy = "category", cascade = CascadeType.ALL, orphanRemoval = true) private List<Product> products; -> Option D

4. Quick Check:

   Use cascade ALL + orphanRemoval for auto-delete [OK]

Hint: Cascade ALL + orphanRemoval deletes children automatically [OK]

Common Mistakes:

• Forgetting cascade causes children to remain
• Using only cascade PERSIST won't delete children
• Ignoring orphanRemoval for child removal