8.1 프록시

엔티티를 조회할 때 연관된 엔티티들이 항상 사용되는 것은 아니다.
예를 들어 회원 엔티티를 조회할 때 연관된 팀 엔티티는 비즈니스 로직에 따라 사용될 때도 있지만 그렇지 않을 때도 있다.

아래 코드를 보자.

@Entity
public class Member {
    private String username; 
    
    @ManyToOne
    private Team team;
    
    public Team getTeam() {
    	return team;
    }
    public String getUsername() {
    	return username;
    }
    ...
}

@Entity
public class Team {
	private String name;
    
    public String getName() {
    	return name;
    }
}

public void printUserAndTeam(String memberId) {
	Member member = em.find(Member.class, memberId);
    Team team = member.getTeam();
    System.out.println("회원 이름: " + member.getUsername());
    System.out.println("소속팀: " + team.getName());
}

public void printUser(String memberId) {
	Member member = em.find(Member.class, memberId);
    System.out.println("회원 이름: " + member.getUsername());
}

printUserAndTeam() 메소드는 memberId로 회원 엔티티를 찾아서 회원은 물론이고 회원과 연관된 팀의 이름도 출력한다. 반면에 printUser() 메소드는 회원 엔티티만 출력하는 데 사용하고 회원과 연관된 팀 엔티티는 전혀 사용하지 않는다.
printUser() 메소드는 회원 엔티티만 사용하므로 em.find()로 회원 엔티티를 조회할 때 회원과 연관된 팀 엔티티까지 데이터베이스에서 함께 조회해 두는 것은 효율적이지 않다.
=> JPA는 이런 문제를 해결하기 위해 엔티티가 실제 사용될 때 까지 데이터베이스 조회를 지연하는 방법인 지연 로딩을 제공한다.
쉽게 이야기해서 team.getName() 처럼 팀 엔티티의 값을 실제 사용하는 시점에 데이터베이스에서 팀 엔티티에 필요한 데이터를 조회하는 것이다. 이 방법을 사용하면 printUser() 메소드는 회원 데이터만 데이터베이스에서 조회해도 된다.
지연 로딩 기능을 사용하려면 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수 있는 가짜 객체인 프록시 객체가 필요하다.

8.1.1 프록시 기초

JPA에서 식별자로 엔티티 하나를 조회할 때는 EntityManager.find()를 사용한다.
이 메소드는 영속성 컨텍스트에 엔티티가 없으면 데이터베이스를 조회한다.
이렇게 엔티티를 직접 조회하면 조회한 엔티티를 실제 사용하든 사용하지 않든 데이터베이스를 조회하게 된다.
엔티티를 실제 사용하는 시점까지 데이터베이스 조회를 미루고 싶으면 EntityManager.getReference() 메소드를 사용하면 된다.

Member member = em.getReference(Member.class, "member1");

이 메소드를 호출할 때 JPA는 데이터베이스를 조회하지 않고 실제 엔티티 객체도 생성하지 않는다. 대신에 데이터 베이스 접근을 위임한 프록시 객체를 반환한다.

프록시의 특징

프록시 클래스는 실제 클래스를 상속 받아서 만들어지므로 실제 클래스와 겉 모양이 같다. 따라서 사용자 입장에서는 이것이 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다.
프록시 객체는 실제 객체에 대한 참조를 보관한다. 그리고 프록시 객체의 메소드를 호출하면 프록시 객체는 실제 객체의 메소드를 호출한다.

프록시 객체의 초기화

프록시 객체는 member.getName() 처럼 실제 사용될 때 데이터베이스를 조회해서 엔티티 객체를 생성하는데 이것을 프록시 객체의 초기화라 한다.

프록시의 초기화 과정을 분석해보자.

1. 프록시 객체에 member.getName()을 호출해서 실제 데이터를 조회한다.
2. 프록시 객체는 실제 엔티티가 생성되어 있지 않으면 영속성 컨텍스트에 실제 엔티티 생성을 요청하는데 이것을 초기화라 한다.
3. 영속성 컨텍스트는 데이터베이스를 조회해서 실제 엔티티 객체를 생성한다.
4. 프록시 객체는 생성된 실제 엔티티 객체의 참조를 Member target 멤버변수에 보관한다.
5. 프록시 객체는 실제 엔티티 객체의 getName()을 호출해서 결과를 반환한다.

프록시의 특징

• 프록시 객체는 처음 사용할 때 한 번만 초기화한다.
• 프록시 객체를 초기화한다고 프록시 객체가 실제 엔티티로 바뀌는 것은 아니다. 프록시 객체가 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근할 수 있다.
• 프록시 객체는 원본 데이터를 상속받은 객체이므로 타입 체크 시에 주의해서 사용해야 한다.
• 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 데이터베이스를 조회할 필요가 없으므로 em.getReference()를 호출해도 프록시가 아닌 실제 엔티티를 반환한다.
• 초기화는 영속성 컨텍스트의 도움을 받아야 가능하다. 따라서 준영속 상태의 프록시를 초기화하면 문제가 발생한다. 하이버네이트는 org.hibernate.LazyInitializationException 예외를 발생시킨다.

준영속 상태와 초기화

준영속 상태와 초기화에 관련된 코드는 다음과 가타.

// MemberProxy 반환
Member member = em.getReference(Member.class, "id1");
transaction.commit();
em.close(); // 영속성 컨텍스트 종료
member.getName(); // 준영속 상태 초기화 시도. org.hibernate.LazyInitializationException 예외 발생

em.close() 메소드로 영속성 컨텍스트를 종료해서 member는 준영속 상태다. member.getName()을 호출하면 프록시를 초기화해야 하는데 영속성 컨텍스트가 없으므로 실제 엔티티를 조회할 수 없기 때문에 예외가 발생한다.

프록시와 식별자

엔티티를 프록시로 조회할 때 식별자 값을 파라미터로 전달하는데 프록시 객체는 이 식별자 값을 보관한다.
프록시 객체는 식별자 값을 가지고 있으므로 식별자 값을 조회하는 team.getId()를 호출해도 프록시를 초기화하지 않는다. 단 엔티티 접근 방식을 프로퍼티로 설정한 경우에만 초기화하지 않는다.
엔티티 접근 방식을 필드로 설정하면 JPA는 getId()메소드가 id만 조회하는 메소드인지 다른 필드까지 활용해서 어떤 일을 하는 메소드인지 알지 못하므로 프록시 객체를 초기화한다.

프록시는 아래 코드처럼 연관관계를 설정할 때 유용하게 사용할 수 있다.

Member member = em.find(Member.class, "membemr1");
Team team = em.getReference(Team.class, "team1"); // SQL을 실행하지 않음
member.setTeam(team);

연관관계를 설정할 때는 식별자 값만 사용하므로 프록시를 사용하면 데이터베이스 접근 횟수를 줄일 수 있다. 참고로 연관관계를 설정할 때는 엔티티 접근 방식을 필드로 설정해도 프록시를 초기화하지 않는다.

프록시 확인

JPA가 제공하는 PersistenceUtil.isLoaded(Object entity) 메소드를 사용하면 프록시 인스턴스의 초기화 여부를 확인할 수 있다. 아직 초기화되지 않은 프록시 인스턴스는 false를 반환한다. 이미 초기화되었거나 프록시 인스턴스가 아니면 true를 반환한다.
조회한 엔티티가 진짜 엔티티인지 프록시로 조회한 것인지 확인하려면 클래스명을 직접 출력해보면 된다.

System.out.println("memberProxy = " + member.getClass().getName());
// 결과: memberProxy = jpabook.domain.Member_$$_javassist_0

다음 예를 보면 클래스 명 뒤에 ..javassist..라 되어 있는데 이것으로 프록시인 것을 확인할 수 있다. 프록시를 생성하는 라이브러리에 따라 출력 결과는 달라질 수 있다.

8.2 즉시 로딩과 지연 로딩

프록시 객체는 주로 연관된 엔티티를 지연 로딩할 때 사용한다.

• 즉시 로딩 : 엔티티를 조회할 때 연관된 엔티티도 함께 조회한다
  • 예 : em.find(Member.class, "member1")를 호출할 때 회원 엔티티와 연관된 팀 엔티티도 함께 조회한다.
  • 설정 방법 : @ManyToOne(fetch = FetchType.EAGER)
• 지연 로딩 : 연관된 엔티티를 실제 사용할 때 조회한다.
  • 예 : member.getTeam().getName() 처럼 조회한 팀 엔티티를 실제 사용하는 시점에 JPA가 SQL을 호출해서 팀 엔티티를 조회한다.
  • 설정 방법 : @ManyToOne(fetch = FetchType.LAZY)

8.2.1 즉시 로딩

즉시 로딩을 사용하려면 @ManyToOne의 fetch 속성을 FetchType.EAGER로 지정한다.

@Entity
public class Member {
	...
    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name="TEAM_ID")
    private Team team;
    ...
}

Member member = em.find(Member.class, "member1");
Team team = member.getTeam(); // 객체 그래프 탐색

회원과 팀을 즉시 로딩으로 설정했기 때문에 em.find(Member.class, "member1")로 회원을 조회하는 순간 팀도 함께 조회한다. 이때 회원과 팀 두 테이블을 조회해야 하므로 쿼리를 2번 실행할 것 같지만 대부분의 JPA 구현체는 즉시 로딩을 최적화 하기 위해 가능하면 조인 쿼리를 사용한다. 여기서는 회원과 팀을 조인해서 쿼리 한 번으로 두 엔티티를 모두 조회한다.

SELECT
	M.MEMBER_ID AS MEMBER_ID,
    M.TEAM_ID AS TEAM_ID,
    M.USERNAME AS USERNAME,
    T.TEAM_ID AS TEAM_ID,
    T.NAME AS NAME
FROM
	MEMBER M LEFT OUTER JOIN TEAM T
    	ON M.TEAM_ID = T.TEAM_ID
WHERE
	M.MEMBER_ID = 'member1'

실행되는 SQL을 분석해보면 회원과 팀을 조인해서 쿼리 한 번으로 조회한 것을 알 수 있다.
이후 member.getTeam()을 호출하면 이미 로딩된 팀1 엔티티를 반환한다.

8.2.2 지연 로딩

지연 로딩을 사용하려면 @ManyToOne의 fetch 속성을 FetchType.LAZY로 지정한다.

@Entity
public class Member {
	...
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name="TEAM_ID")
    private Team team;
    ...
}

Member member = em.find(Member.class, "member1");
Team team = member.getTeam(); // 객체 그래프 탐색
team.getName(); // 팀 객체 실제 사용

회원과 팀을 지연 로딩으로 설정했기 때문에 em.find(Member.class, "member1")를 호출하면 회원만 조회하고 팀은 조회하지 않는다. 조회한 회원의 team 멤버변수에 프록시 객체를 넣어둔다.

Team team = member.getTeam(); // 프록시 객체

반환된 팀 객체는 프록시 객체다. 이 프록시 객체는 실제 사용될 때까지 데이터 로딩을 미룬다. 그래서 지연로딩이라고 한다.

team.getName(); // 팀 객체 실제 사용

이처럼 실제 데이터가 필요한 순간이 되어서야 데이터베이스를 조회해서 프록시 객체를 초기화한다.

em.find(Member.class, "member1") 호출 시 실행되는 SQL은 다음과 같다.

SELECT * FROM MEMBER
WHERE MEMBER_ID = 'member1'

team.getName() 호출로 프록시 객체가 초기화되면서 실행되는 SQL은 다음과 같다.

SELECT * FROM TEAM
WHERE TEAM_ID = 'team1'

8.2.3 즉시 로딩, 지연 로딩 정리

대부분의 애플리케이션 로직에서 회원과 팀 엔티티를 같이 사용한다면 SQL 조인을 사용해서 회원과 팀 엔티티를 한번에 조회하는 것이 더 효율적이다. 그렇기 때문에 즉시 로딩, 지연 로딩 둘중에 뭐가 더 나은것인지는 상황에 따라 다르다.

• 지연 로딩 : 연관된 엔티티를 프록시로 조회한다. 프록시를 실제 사용할 때 초기화하면서 데이터베이스를 조회한다.
• 즉시 로딩 : 연관된 엔티티를 즉시 조회한다. 하이버네이트는 가능하면 SQㅣ 조인을 사용해서 한 번에 조회한다.

8.3 지연 로딩 활용

사내 주문 관리 시스템을 개발한다고 가정해보자.
사용할 모델을 분석해보자.

• 회원은 팀 하나에만 소속할 수 있다. (N : 1)
• 회원은 여러 주문내역을 가진다. (1 : N)
• 주문내역은 상품 정보를 가진다. (N : 1)

애플리케이션 로직을 분석해보니 다음과 같았다.

• Member와 연관된 Team은 자주 함께 사용되었다. 그래서 Member와 Team은 즉시 로딩으로 설정했다.
• Member와 연관된 Order는 가끔 사용되었다. -> Member와 Order는 지연 로딩으로 설정했다.
• Order와 연관된 Product는 자주 함께 사용되었다. -> Order와 Product는 즉시 로딩으로 설정했다.

@Entity
public class Member {
    @Id 
    private String id; // 아이디
	private String username; // 이름
    private Integer age;

    @OneToMany(mappedBy = "member", fetch = FetchType.LAZY)
    private List<Order> orders = new ArrayList<Order>();

    @ManyToOne(fetch = FetchType.EAGER)
    private Team team;
    ...
}

회원과 팀의 연관관계를 FetchType.EAGER로 설정했다. 따라서 회원 엔티티를 조회하면 연관된 팀 엔티티도 즉시 조회한다.
회원과 주문내역의 연관관계를 FetchType.LAZY로 설정했다. 따라서 회원 엔티티를 조회하면 연관된 주문내역 엔티티는 프록시로 조회해서 실제 사용될 때까지 로딩을 지연한다.
회원과 팀은 즉시 로딩으로 설정했기 때문에 회원을 조회할 때 연관된 teamA도 함께 조회한다.
반면에 회원과 주문내역은 지연로딩으로 설정했으므로 결과를 프록시로 조회해서 회원을 조회할 때 SQL에 전혀 나타나지 않는다.

8.3.1 프록시와 컬렉션 래퍼

프록시 객체는 실제 자신이 사용될 때 까지 데이터베이스를 조회하지 않는다.

주문 내역을 조회해보자.

Member member = em.find(Member.class, "member1");
List<Order> orders = member.getOrders();
System.out.println("orders = " + orders.getClass().getName());
// 결과: orders = org.hibernate.collection.internal.PersistentBag

컬렉션 래퍼 : 하이버네이트는 엔티티를 영속 상태로 만들 때 엔티티에 컬렉션이 있으면 컬렉션을 추적하고 관리할 목적으로 원본 컬렉션을 하이버네이트가 제공하는 내장 컬렉션으로 변경하는 것
출력 결과를 보면 컬렉션 래퍼인 PersistentBag이 반환된 것을 확인할 ㅅ ㅜ있다.

엔티티를 지연 로딩하면 프록시 객체를 사용해서 지연 로딩을 수행하지만 주문 내역 같은 컬렉션은 컬렉션 래퍼가 지연 로딩을 처리해준다. but, 컬렉션 래퍼도 컬렉션에 대한 프록시 역할을 하므로 따로 구분하지 않고 프록시로 부르겠다.

member.getOrders()가 아닌 member.getOrders().get(0) 처럼 컬렉션에서 실제 데이터를 조회할 때 데이터베이스를 조회해서 초기화한다.

8.3.2 JPA 기본 페치 전략

fetch 속성의 기본 설정값은 다음과 같다.

• @ManyToOne, @OneToOne: 즉시 로딩(FetchType.EAGER)
• @OneToMany, @ManyToMany: 지연 로딩(FetchType.LAZY)

JPA의 기본 페치 전략은 연관된 엔티티가 하나면 즉시 로딩을, 컬렉션이면 지연 로딩을 사용한다. 컬렉션을 로딩하는 것은 비용이 많이 들고 잘못하면 너무 많은 데이터를 로딩할 수 있기 때문이다.
추천하는 방법은 모든 연관관계에 지연 로딩을 사용하는 것이다. 그리고 애플리케이션 개발이 어느 정도 완료단계에 왔을 때 실제 사용하는 상황을 보고 꼭 필요한 곳에만 즉시 로딩을 사용하도록 최적화하면 된다.

8.3.3 컬렉션에 FetchType.EAGER 사용시 주의점

• 컬렉션을 하나 이상 즉시 로딩하는 것은 권장하지 않는다.
• 컬렉션 즉시 로딩은 항상 외부 조인을 사용한다.

FetchType.EAGER 설정과 조인 전략을 정리하면 다음과 같다.

• @ManyToOne, @OneToOne
  • (optional = false): 내부 조인
  • (optional = true): 외부 조인
• @OneToMany, @ManyToMany
  • (optional = false): 외부 조인
  • (optional = true): 외부 조인

8.4 영속성 전이: CASCADE

특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상테로 만들고 싶으면 영속성 전이 기능을 사용하면 된다. JPA는 CASCADE 옵션으로 영속성 전이를 제공한다. 이를 사용하면 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장할 수 있다.
예제를 통해 알아보자.

@Entity
public class Parent {
    @Id @GeneratedValue
    private ParentId id;
    
    @OneToMany(mappedBy = "parent")
    private List<Child> children = new ArrayList<>();
    ...
}

@Entity
public class Child {
    @Id @GeneratedValue
    private Long id;
    
    @ManyToOne
    private Parent parent;
    ...
}

위 코드처럼 부모 엔티티가 여러 자식 엔티티를 가지고 있다.
만약 부모 1명에 자식 2명을 저장한다면 아래 코드와 같은 코드를 작성할 것이다.

private static void saveNoCascade(EntityManger em) {
	// 부모 저장
    Parent parent = new Parent();
    em.persist(parent);
    
    // 1번 자식 저장
    Child child1 = new Child();
    child1.setParent(parent); // 자식 -> 부모 연관관계 설정
    parent.getChildren().add(child1); // 부모 -> 자식
    em.persist(child1);
    
    // 2번 자식 저장
    Child child2 = new Child();
    child2.setParent(parent); // 자식 -> 부모 연관관계 설정
    parent.getChildren().add(child2); // 부모 -> 자식
    em.persist(child2);
}

JPA에서 엔티티를 저장할 때 연관된 모든 엔티티는 영속 상태여야 한다. 따라서 위 코드를 보면 부모 엔티티를 영속 상태로 만들고 자식 엔티티도 각각 영속 상태로 만든다. 이럴 때 영속성 전이를 사용하면 부모만 영속 상태로 만들면 연관된 자식까지 한 번에 영속 상태로 만들 수 있다.

8.4.1 영속성 전이: 저장

영속성 전이를 활성화하는 CASCADE 옵션을 적용해보자.

@Entity
public class Parent {
    ...
    @OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST)
    private List<Child> children = new ArrayList<>();
    ...
}

부모를 영속화할 때 연관된 자식들도 함께 영속화하라고 cascade = CascadeType.PERSIST 옵션을 설정했다. 이 옵션을 적용하면 아래 코드처럼 간편하게 부모와 자식 엔티티를 한 번에 영속화할 수 있다.

private static void saveWithCascade(EntityManger em) {
	Child child1 = new Child();
    Child child2 = new Child();
    
    Parent parent = new Parent();
    child1.setParent(parent); // 연관관계 추가
    child2.setParent(parent); // 연관관계 추가
    parent.getChildren().add(child1);
    parent.getChildren().add(child2);
    
    // 부모 저장, 연관된 자식들 저장
    em.persist(parent);

부모만 영속화하면 CascadeType.PERSIST로 설정한 자식 엔티티까지 함께 영속화해서 저장한다. 데이터베이스에 입력된 데이터를 확인해보자.

SELECT * FROM CHILD

이 코드의 쿼리 결과를 보면 데이터가 정상적으로 2건 입력된 것을 확인할 수 있다.

8.4.2 영속성 전이: 삭제

방금 저장한 부모와 자식 엔티티를 모두 제거하려면 다음 코드와 같이 각각의 엔티티를 하나씩 제거해야 한다.

Parent findParent = em.find(Parent.class, 1L);
Child findChild1 = em.find(Child.class, 1L);
Child findChild2 = em.find(Child.class, 2L);

em.remove(findChild1);
em.remove(findChild2);
em.remove(findParent);

영속성 전이는 엔티티를 삭제할 때도 사용할 수 있다.
CascadeType.REMOVE로 설정하고 다음 코드처럼 부모 엔티티만 삭제하면 연관된 자식 엔티티도 함께 삭제된다.

Parent findParent = em.find(Parent.class, 1L);
em.remove(findParent);

코드를 실행하면 DELETE SQL을 3번 실행하고 부모는 물론 연관된 자식도 모두 삭제한다. 삭제 순서는 외래 키 제약 조건을 고려해서 자식을 먼저 삭제하고 부모를 삭제한다.
만약 CascadType.REMOVE를 설정하지 않고 해당 코드를 실행한다면? -> 부모 엔티티만 삭제된다. -> 데이터베이스의 부모 로우를 삭제하는 순간 자식 테이블에 걸려 있는 외래키 제약조건으로 인해 데이터베이스에서 외래키 무결성 예외가 발생한다.

8.4.3 CASCADE의 종류

CascadeType 코드를 보면 다양한 옵션이 있는 것을 확인할 수 있다.

public enum CascadeType {
	ALL, // 모두 적용
    PERSIST, // 영속
    MERGE, // 병합
    REMOVE, // 삭제
    REFRESH, // REFRESH
    DETACH // DETACH
}

다음 코드처럼 여러 속성을 같이 사용할 수 있다.

cascade = {CascadeType.PERSIST, CascadeType.REMOVE}

참고로 CascadeType.PERSIST, CascadeType.REMOVE는 em.persist(), em.remove()를 실행할 때 바로 전이가 발생하지 않고 플러시를 호출할 때 전이가 발생한다.

8.5 고아 객체

JPA는 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 기능을 제공하는데 이것을 고아 객체 제거라 한다.이 기능을 사용해서 부모 엔티티의 컬렉션에서 자식 엔티티의 참조만 제거하면 자식 엔티티가 자동으로 삭제 되도록 해보자.

@Entity
public class Parent {
    @Id @GeneratedValue
    private ParentId id;

    @OneToMany(mappedBy = "parent", orphanRemoval = true)
    private List<Child> childdren = new ArrayList<>();
}

위 코드를 보면 고아 객체 제거 기능을 활성화하기 이해 컬렉션에 orphanRemoval = true를 설정했다. 이제 컬렉션에서 제거한 엔티티는 자동으로 삭제된다.

사용 코드를 보자.

Parent parent1 = em.find(Parent.class, id);
parent1.getChildren().remove(0); // 자식 엔티티를 컬렉션에서 제거

실행 결과 SQL은 다음과 같다.

DELETE FROM CHILD WHERE ID=?

사용 코드를 보면 컬렉션에서 첫 번째 자식을 제거했다. orphanRemoval = true 옵션으로 인해 컬렉션에서 엔티티를 제거하면 데이터베이스의 데이터도 삭제된다.
고아 객체 제거 기능은 영속성 컨텍스트를 플러시할 때 적용되므로 플러시 시점에 DELETE SQL이 실행된다.
모든 자식 엔티티를 제거하려면 다음 코드처럼 컬렉션을 비우면 된다.

parent1.getChildren().clear();

이 기능은 참조하는 곳이 하나일 때만 사용해야 한다. 즉, 특정 엔티티가 개인 소유하는 엔티티에만 이 기능을 적용해야 한다. 이런 이유로 orphanRemoval은 @OneToOne, @OneToMany에만 사용할 수 있다.

8.6 영속성 전이 + 고아 객체, 생명주기

CascadeType.ALL + orphanRemoval = true를 동시에 사용하면 어떻게 될까?
일반적으로 엔티티는 EntityManager.persist()를 통해 영속화되고 EntityManger.remove()를 통해 제거된다. 이것은 엔티티 스스로 생명주기를 관리한다는 뜻이다.
그런데 두 옵션을 모두 활성화하면 부모 엔티티를 통해서 자식의 생명 주기를 관리할 수 있다.

예제를 보자.
자식을 저장하려면 부모에 등록만 하면 된다. (CASCADE)

Parent parent = em.find(Parent.class, parentId);
parent.addChild(child1);

자식을 삭제하려면 부모에서 제거하면 된다. (orphanRemoval)

Parent parent = em.find(Parent.class, parentId);
parent.getChildren().remove(removeObject);