Relationships and transactions

Shared core

The chapter below remains the canonical explanation for both goals. Keep its model, examples, and trade-offs shared; only the deliberate practice changes with the route.

Learn deeply: build evidence

Use this chapter’s TaskFlow work to make one small, observable change. Run the stated acceptance checks before recording practice.

Prepare for interviews: explain the trade-off

Without notes, explain the boundary this chapter protects, one concrete implementation decision, and the cost of a tempting shortcut. Then answer one follow-up using the chapter’s own example.

Section 1The new TaskFlow model

@Entity
class AppUser {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    @Column(nullable = false, unique = true)
    private String email;
}

@Entity
class Project {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    @Column(nullable = false)
    private String name;
    @ManyToOne(optional = false)
    private AppUser owner;
}

@Entity
class Task {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    @Column(nullable = false)
    private String title;
    private boolean done;
    @ManyToOne(optional = false)
    private Project project;
}

Section 2Mission: add projects and task ownership

public interface TaskRepository extends JpaRepository<Task, Long> {
    List<Task> findByProjectId(Long projectId);
}

@Service
public class TaskService {
    private final TaskRepository tasks;
    private final ProjectRepository projects;

    public TaskService(TaskRepository tasks, ProjectRepository projects) {
        this.tasks = tasks;
        this.projects = projects;
    }

    public Task createInProject(Long projectId, String title, boolean done) {
        Project project = projects.findById(projectId).orElseThrow(() -> new ProjectNotFoundException(projectId));
        Task task = new Task();
        task.setTitle(title);
        task.setDone(done);
        task.setProject(project);
        return tasks.save(task);
    }

    public List<Task> listForProject(Long projectId) {
        if (!projects.existsById(projectId)) {
            throw new ProjectNotFoundException(projectId);
        }
        return tasks.findByProjectId(projectId);
    }
}

Section 3Transactions: one service method, one unit of work

Use @Transactional when one service method changes multiple rows and those changes must succeed or fail together. Do not scatter it on every class by habit; put it where the business operation needs one unit.

@Transactional
public Project createProjectWithFirstTask(Long ownerId, String projectName, String firstTaskTitle) {
    AppUser owner = users.findById(ownerId).orElseThrow(() -> new UserNotFoundException(ownerId));

    Project project = new Project();
    project.setName(projectName);
    project.setOwner(owner);
    Project saved = projects.save(project);

    Task task = new Task();
    task.setTitle(firstTaskTitle);
    task.setProject(saved);
    tasks.save(task);

    return saved;
}

If saving the task fails, the project insert should roll back too. That is the transaction boundary.

Section 4Mission: prepare TaskFlow for security

public interface ProjectRepository extends JpaRepository<Project, Long> {
    List<Project> findByOwnerId(Long ownerId);
}

public List<Project> listForOwner(Long ownerId) {
    if (!users.existsById(ownerId)) {
        throw new UserNotFoundException(ownerId);
    }
    return projects.findByOwnerId(ownerId);
}

Section 5N+1 awareness without panic

JPA can accidentally run one query for the parent rows and then one query per child row. That is the N+1 problem. You do not need to master performance tuning today; you only need to recognize the smell.