3주차 - Database - PostgreSQL, JPA

Chaeyoung Moon·2024년 9월 16일
0

SOPT

목록 보기
4/6
post-thumbnail

SOPT 34기 SERVER 3주차 🔑keyword🔑 과제

1️⃣ 엔티티의 생명주기

📌 엔티티의 생명주기

  • 비영속(new/transient)
    : * 영속성 컨텍스트와 전혀 관계가 없는 상태
    - 엔티티 객체를 생성한 상태. 순수한 객체 상태이며 아직 저장하지 않았기 때문에 영속성 컨텍스트나 데이터베이스와 관련이 없음
    // 객체를 생성한 상태(비영속)
    Member member = new Member();
    member.setId("member1");
    member.setUsername("회원1");
  • 영속(managed)
    : * 영속성 컨텍스트에 저장된 상태
    - 엔티티 매니저를 통해서 엔티티를 영속성 컨텍스트에 저장한 상태. 이제 회원 엔티티는 비영속 상태에서 영속 상태가 된다. 즉, 이제 회원 엔티티는 영속성 컨텍스트에 의해 관리된다.
    (em.find()나 JPQL을 사용해서 조회한 엔티티도 영속성 컨텍스트가 관리하는 영속 상태이다.)
    // 객체를 저장한 상태(영속)
    em.persist(member);
  • 준영속(detached)
    : * 영속성 컨텍스트에 저장되었다가 분리된 상태
    - 영속성 컨텍스트가 관리하던 영속 상태의 엔티티를 영속성 컨텍스트가 관리하지 않으면 준영속 상태가 된다. 특정 엔티티를 준영속 상태로 만들려면 em.detach()를 호출하면 된다.
    - em.close()를 호출해서 영속성 컨텍스트를 닫거나 em.clear()를 호출해서 영속성 컨텍스트를 초기화해도 영속성 컨텍스트가 관리하던 영속 상태의 엔티티는 준영속 상태가 된다.
    // 회원 엔티티를 영속성 컨텍스트에서 분리 - 준영속 상태
    em.detach(member);
  • 삭제(removed)
    : 삭제된 상태
    - 엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제한다.
    // 객체를 삭제한 상태(삭제)
    em.remove(member);
  • 영속성 컨텍스트(persistence context)
    : 엔티티를 영구 저장하는 환경으로, 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.

2️⃣ Java의 Checked Exception과 Unchecked Exception

📌 자바(Java)의 예외

  • 체크 예외(Checked Excepiton)
  • 에러(Error)
  • 언체크 예외(Unchecked Exception)

위의 에러 및 예외와 관련된 클래스들의 계층구조를 나타내면 아래의 그림과 같다.

블로그 - Java Exception의 계층구조

그림과 같이 Throwable 클래스를 기준으로 Error, Exception 클래스로 나눈다.

그렇다면 Error와 Exception은 무엇이 다를까?

📌 에러(Error)

시스템에 비정상적인 상황이 발생했을 때 ‘에러(Error)’가 발생한다. 대표적인 예시로 메모리 부족(OutOfMemoryError)과 스택오버플로우(StackOverflowError)처럼 복구할 수 없는 것들은 에러(Error)를 통해 처리한다.

⇒ 에러(Error)는 개발자가 예측하기 쉽지 않고 처리할 수 있는 방법도 따로 없다는 점이 특징이다.

📌 예외(Exception)

프로그램 실행 중에 개발자의 실수로 예기치 않은 상황이 발생했을 때 예외(Exception)이 발생한다. 예외(Exception)의 예시로는 ArrayIndexOutOfBoundsException을 들 수 있는데, 배열의 범위를 벗어났을 때를 처리한다. 또, NullPointerException은 값이 Null 참조변수를 참조할 때를 처리한다. 다른 예시로는, 존재하지 않는 파일의 이름을 입력했을 때, FileNotFoundException으로 처리해줄 수 있다.

그리고 이 예외는 에러(Error)와 달리 복구할 수 없을 정도의 치명적인 오류가 아니라는 점이 특징이고, 체크 예외(Checked Exception)와 언체크 예외(Unchecked Exception) 두 가지로 구분할 수 있다.

📌 체크 예외(Checked Exception)

위의 그림(계층구조)에서 RuntimeException의 하위 클래스가 아니면서 Exception 클래스의 하위클래스들에 해당한다. 체크 예외는 반드시 에러 처리를 해야하는 특징을 가지고 있다(try/catch or throw). 체크 예외에 해당하는 예시를 들어보면 다음과 같다.

  • FileNotFoundException : 존재하지 않는 파일의 이름을 입력했을 때
  • ClassNotFoundException : 실수로 클래스의 이름을 잘못 적었을 때

📌 언체크 예외(Unchecked Exception)

위의 그림(계층구조)에서 RuntimeException의 하위 클래스들에 해당한다. 특징적인 점은, 체크 예외(Checked Exception)와는 달리 * 반드시 에러처리를 해야할 의무는 없다(즉, 에러 처리를 강제하지 않는다)는 점이다.

말 그대로 실행 중, runtime 중에 발생할 수 있는 예외를 의미하고 예시를 들어보면 다음과 같다.

  • ArrayIndexOutOfBoundException : 배열의 범위를 벗어났을 때
  • NullPointerException : null이 참조 변수를 참조했을 때
  • 반드시 에러처리를 해야할 의무가 없다?

: RuntimeException은 개발자의 실수로 발생하는 것들이기 때문에 에러를 강제하지 않음 (📍이에 대한 예시는 아래와 같다)

public class ArrayTest {
	public static void main(String[] args) {
		try {
			int [] list = {1,2,3,4,5};
			System.out.println(list[0]);
		} catch (ArrayIndexOutOfBoundsException e) {
				e.printStackTrace();
		}
	}
}

위의 코드는 단순히 배열을 만들어서 배열의 원소를 출력하고자 하는데 , try/catch 문을 꼭 사용해야한다.

Checked ExceptionUnchecked Exception
처리여부반드시 예외를 처리해야 함명시적인 처리를 강제하지 않음
확인시점컴파일 단계실행단계
예외발생시 트랜잭션 처리roll-back 하지 않음roll-back 함
대표 예외Exception의 상속받는 하위클래스 중 Runtime Exception을 제외한 모든 예외
  • IOException
  • SQLException | RuntimeException 하위 예외
  • NullPointerException
  • IllegalArgumentException
  • IndexOutOfBoundException
  • SystemException |

📌 Checked vs Unchecked

  • Checked Exception : Rollback이 되지 않음. transaction이 commit까지 완료.
  • Unchecked Exception : Rollback이 됨.

⇒ try-catch로 묶어줄 필요가 있을 때만 Exception 클래스를 확장하고, 일반적으로 실행시 예외를 처리할 수 있는 경우에는 RuntimeException 클래스를 확장해 Unchecked Exception을 사용하는 게 좋다.


🔗 참고 자료 - keyword 별

1️⃣ 엔티티의 생명주기

🔗 #1-1 자바 ORM 표준 JPA 프로그래밍

2️⃣ Java의 Checked Exception과 Unchecked Exception

🔗 #2-1 블로그 - Gyun’s 개발일지(Checked vs Unchecked

🔗 #2-2 블로그 - Taehyun Hwang(Java Exception 종류)

0개의 댓글