JPA의 영속성 컨텍스트에 대해서 설명해 주세요

영속성 컨텍스트란?

엔티티를 영구 저장하는 환경 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다. 엔티티 매니저를 통해 엔티티를 저장하거나 조회하면 엔티티 메니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.

영속성 컨텍스트의 특징

• 엔티티 매니저를 생성할 때 하나 만들어진다.
• 엔티티 매니저를 통해서 영속성 컨텍스트에 접근하고 관리할 수 있다.

엔티티의 생명주기

• 비영속성 (new/transient) : 영속성 컨텍스트와 전혀 관계가 없는 상태

  Member member = new Member();
  

  엔티티 객체를 생성했지만 아직 영속성 컨텍스트에 저장하지 않는 상태

• 영속(managed) : 영속성 컨텍스트에 저장된 상태 엔티티 매니저를 통해서 엔티티를 영속성 컨텍스트에 저장한 상태를 말하며 영속성 컨텍스트에 의해 관리

em.persist(member);

• 준영속(derached) : 영속성 컨텍스트에 저장되었다가 분리된 상태

영속성 컨텍스트가 관리하던 영속 상태의 엔티티 더이상 관리하지 않으면 준영속 상태가 됨 엔티티를 준영속 상태로 만들려면 em.datach()를 호출하면 된다.

// 엔티티를 영속성 컨텍스트에 분리해 준영속 상태로 만든다.
em.detach(member);
// 영속성 컨텍스트를 비워도 관리되던 준영속 상태가 된다.
em.claer();
// 영속성 컨텍스트를 종료해도 관리되던 엔티티는 준영속 상태가 된다.
em.close();

준영속 상태의 특징

- 1차 캐시, 쓰기 지연, 변경 감지, 지연 로딩을 포함한 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않는다.
- 식별자 값을 가지고 있다.

• 삭제(removed) : 삭제된 상태
  엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제

em.remove(member);

영속성 컨텍스트의 특징

영속성 컨텍스트의 식별자 값 영속성 컨텍스트는 엔티티를 식별자 값으로 구분한다. 따라서 영속 상태는 식별자 값이 반드시 있어야 한다.

영속성 컨텍스트와 데이터베이스 저장 JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영하는데 이를 flush라 한다.

영속성 컨텍스트가 엔티티를 관리하면 다음과 같은 장점이 있다.

1. 1차 캐시
2. 동일성 보장
3. 트랜잭션을 지원하는 쓰기 지연
4. 변경 감지
5. 지연 로딩

1차 캐시

영속성 컨텍스트 내부에는 캐시가 있는데 이를 1차 캐시라고 한다. 영속 상태의 엔티티를 이곳에 저장한다. 1차 캐시의 키는 식별자 값(데이터베이스의 기본 키)이고 값은 엔티티 인스턴스이다.

JPA의 EntityManager 인스턴스인 em을 사용하여 식별자 값이 "member1"인 Member 엔티티를 데이터베이스에서 조회하는 코드

// em.find(엔티티 클래스 타입, 식별자 값);
Member member = em.find(Member.class, "member1");

조회의 흐름

• 1차 캐시에서 엔티티를 찾는다.
• 있으면 메모리에 있는 1차 캐시에서 엔티티를 조회한다.
• 없을 경우 데이터베이스에서 조회한다.
• 조회한 엔티티를 생성해 1차 캐시에 저장한다. (엔티티를 영속상태로 만든다)
• 조회한 엔티티를 반환한다.

영속엔티티의 동일성 보장

영속성 컨텍스트는 엔티티의 동일성을 보장한다.

1차캐시를 통해 동일성을 보장한다. 완전히 같은 엔티티를 반환해준다.

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
Ststem.out.print(a==b) // true

동일성 비교 : 실제 인스턴스가 같다. ==을 사용해 비교한다.

동등성 비교 : 실제 인스턴스는 다를 수 있지만 인스턴스가 가지고 있는 값이 같다. equals() 메소드를 구현해서 비교한다.

트랜잭션을 지원하는 쓰기 지연 ( 데이터베이스 접근을 최적화)

em.find(member)를 사용해 member를 저장해도 바로 INSERT SQL이 DB에 보내지는 것이 아니다. 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 내부 쿼리 저장소에 INSERT SQL을 모아둔다. 그리고 트랜잭션을 커밋할 때 모아둔 쿼리를 DB에 보낸다. 이것을 트랜잭션을 지원하는 쓰기 지연이라 한다.

영속 상태의 엔티티에 대한 변경 사항을 즉시 데이터베이스에 반영하지 않고, 대신 내부적으로 SQL을 저장해두는 것입니다. 그 후, 트랜잭션이 커밋되는 시점에 이 모아둔 SQL을 한 번에 데이터베이스에 전송한다. 이 방식을 통해 데이터베이스 접근 횟수를 최소화하며 성능을 향상시킬 수 있다.

예시로, **em.persist(member)**를 사용해 엔티티를 영속 상태로 만들면, 이 메서드는 즉각적으로 데이터베이스에 INSERT SQL을 보내지 않는다. 대신, SQL은 내부에 저장되고, 트랜잭션 커밋 시에 데이터베이스로 전송된다.

즉, JPA의 이런 특성을 이해하고 활용하면, 애플리케이션의 데이터베이스 접근을 보다 효율적으로 관리할 수 있다.

변경 감지

JPA로 엔티티를 수정할 때는 단순히 엔티티를 조회해서 데이터를 변경하면 된다. JPA는 엔티티의 변경을 감지하여 수정된 엔티티에 대한 UPDATE SQL을 자동으로 생성하고, 트랜잭션 커밋 시점에 데이터베이스에 반영한다. 이를 더티 체킹이라고 한다.

변경감지의 흐름

• 트랜잭션을 커밋하면 엔티티 매니저 내부에서 먼저 프러시가 호출된다.
• 엔티티와 스냅샷을 비교하여 변경된 엔티티를 찾는다.
• 변경된 엔티티가 있으면 수정 쿼리를 생성해서 쓰지 지연 SQL 저장소에 저장한다.
• 쓰기 지연 저장소의 SQL을 플러시한다.
• 데이터베이스 트랜잭션을 커밋한다.

변경 감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티만 적용된다.

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin();

Memeber member = em.find(Member.class, "member1");
member.setName("HA");

transaction.commit();

지연 로딩 ( 필요한 데이터만 로딩하는 성능 최적화 전략)

JPA는 연관된 엔티티를 즉시 로딩하는 것이 아니라, 실제로 사용하는 시점에 데이터베이스에서 로딩하는 지연로딩을 지원한다.

연관된 엔티티의 로딩을 실제로 사용하는 시점까지 늦추는 방법입니다. 이는 성능 최적화의 한 방법으로, 필요한 데이터만 로딩하고 불필요한 데이터의 로딩을 방지함으로써 성능을 향상시킬 수 있다.

예를 들어, 특정 엔티티와 연관된 다른 엔티티들이 있을 때, 이 연관된 엔티티들을 모두 즉시 로딩하면 데이터베이스에 부담을 주고 애플리케이션의 성능을 저하시킬 수 있다. 그러나 지연 로딩을 사용하면, 이 연관된 엔티티들을 실제로 필요로 하는 시점에만 로딩하므로 불필요한 데이터베이스 접근을 줄일 수 있다.

JPA에서는 @ManyToOne, @OneToMany 등의 관계 매핑 어노테이션에 fetch 속성을 **FetchType.LAZY**로 설정하여 지연 로딩을 구현할 수 있다. 이렇게 하면 해당 연관 엔티티는 필요할 때까지 로딩이 지연되며, 실제로 엔티티에 접근하는 시점에 데이터베이스에서 로딩된다.

플러시 (변경 사항을 데이터베이스에 반영하는 과정)

영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 과정이다. 영속성 컨텍스트의 엔티티를 지우는게 아니라 변경 내용을 데이터베이스에 동기화하는 것이다.

영속성 컨텍스트에 있는 변경 내용을 데이터베이스에 반영하는 과정이다. 플러시는 주로 트랜잭션을 커밋하는 시점에 자동으로 발생하며, 이 때 영속성 컨텍스트에 저장된 쿼리(INSERT, UPDATE, DELETE 등)가 데이터베이스에 전송된다. 또한, 필요에 따라 개발자가 직접 em.flush() 메서드를 호출하여 플러시를 수행할 수도 있다.

플러시의 흐름

• 변경 감지가 동작해서 스냅샷과 비교해서 수정된 엔티티를 찾는다.
• 수정된 엔티티에 대해서 수정 쿼리를 만들거나 SQL 저장소에 등록한다.
• 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.

플러시하는 방법

• em.flush()
• 트랜잭션 커밋시 자동 호출
• JPQL 쿼리 실행시 자동 호출

Spring MVC에서의 예외 처리 기법에 대해서 설명해주세요.

Spring MVC에서 예외 처리를 위한 여러 가지 기법이 있습니다.

1. @ExceptionHandler: 컨트롤러 클래스 내에서 발생한 예외를 처리할 메서드를 지정하는 데 사용되는 애노테이션입니다. 이 메서드는 예외 클래스를 인수로 받아 처리하며, 동일한 컨트롤러 클래스 내에서 발생한 해당 유형의 예외를 처리할 수 있습니다.

javaCopy code
@Controller
public class MyController {
    @RequestMapping("/somepage")
    public String somepage() {
        //...
        throw new CustomException("Some error occurred");
    }

    @ExceptionHandler(CustomException.class)
    public ModelAndView handleCustomException(CustomException ex) {
        ModelAndView model = new ModelAndView("error");
        model.addObject("exception", ex);
        return model;
    }
}

2. @ControllerAdvice: 전역 예외 처리를 위한 클래스에 사용되는 애노테이션입니다. 이를 사용하면 애플리케이션 전체에서 발생하는 예외를 처리하는 별도의 클래스를 정의할 수 있습니다. 이 클래스 내부에서는 @ExceptionHandler 애노테이션을 사용하여 처리할 예외 유형을 지정할 수 있습니다.

javaCopy code
@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(CustomException.class)
    public ModelAndView handleCustomException(CustomException ex) {
        ModelAndView model = new ModelAndView("error");
        model.addObject("exception", ex);
        return model;
    }
}

3. 예외 처리용 핸들러 메서드: 컨트롤러에서 발생한 예외를 처리하는 메서드를 지정하는 데 사용됩니다. Spring 3.2 이전 버전에서 사용되었던 예외 처리 방식으로, SimpleMappingExceptionResolver 또는 HandlerExceptionResolver 인터페이스를 구현하여 예외 처리 클래스를 정의할 수 있습니다.

javaCopy code
public class CustomExceptionResolver extends SimpleMappingExceptionResolver {
    @Override
    protected ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        if (ex instanceof CustomException) {
            // 처리할 예외 유형에 따른 처리 로직
        }
        return super.doResolveException(request, response, handler, ex);
    }
}

4. ErrorViewResolver 인터페이스 구현: Spring Boot에서 사용 가능한 예외 처리 방식으로 예외가 발생할 때 호출되며, 반환되는 ModelAndView 객체를 통해 에러 페이지를 지정할 수 있습니다.

javaCopy code
@Component
public class CustomErrorViewResolver implements ErrorViewResolver {
    @Override
    public ModelAndView resolveErrorView(HttpServletRequest request, HttpStatus status, Map<String, Object> model) {
        ModelAndView modelAndView = new ModelAndView("error");
        modelAndView.addObject("status", status.value());
        modelAndView.addAllObjects(model);
        return modelAndView;
    }
}

이러한 기법들을 사용하여 Spring MVC 애플리케이션에서 발생하는 예외를 효과적으로 처리할 수 있습니다. 이렇게 처리된 예외는 사용자 친화적인 에러 메시지를 표시하거나, 로깅을 통해 개발자가 원인을 찾아 수정할 수 있는 정보를 제공하는 등의 방식으로 처리됩니다.

여기에 추가로, 예외 처리 방법을 조합하여 더욱 강력한 예외 처리 전략을 구축할 수도 있습니다. 예를 들어, @ExceptionHandler를 사용하여 컨트롤러별 예외 처리를 구현하고, @ControllerAdvice를 사용하여 전역적인 예외 처리를 수행하는 등의 방법을 사용할 수 있습니다.

예외 처리 구현 시 고려사항

1. 예외 유형: 예외 유형에 따라 적절한 에러 메시지를 표시하거나, 처리 방식을 달리해야 할 수 있습니다. 예를 들어, 사용자 입력 오류와 시스템 오류는 다른 방식으로 처리되어야 할 수 있습니다.
2. 에러 페이지: 예외가 발생했을 때 사용자에게 표시할 에러 페이지를 준비하고, 이를 적절한 예외 처리 메서드에서 반환해야 합니다. 에러 페이지는 사용자 친화적이고 이해하기 쉬운 메시지를 제공해야 합니다.
3. 로깅: 예외 처리 과정에서 로깅을 통해 발생한 예외에 대한 정보를 기록할 수 있습니다. 이를 통해 개발자는 시스템 오류의 원인을 찾고, 이를 수정하는 데 도움을 받을 수 있습니다.
4. 예외 전파: 예외를 적절한 수준에서 처리하고, 필요한 경우 상위 계층으로 전파할 수 있어야 합니다. 이를 통해 예외 처리의 책임을 명확하게 분리하고, 적절한 수준에서 처리할 수 있습니다.

To do

• [x] 아침운동하기
• [x] 코테10문제풀기
• [x] 자바 3페이지 읽기
• [ ] 이력서 수정하기 (전체적으로 다시 수정하기)
• [x] 지원하기 1곳 이상
• [ ] cs책 읽고 정리하기
• [ ] aws 서밋 내용 정리 하기 (사진 너무 많아용)
• [x] 이력서 과제
• [x] 리눅스 계보와 윈도우, 맥 의 차이점 찾아보기!! 
• [x] 폰 노이만 아키텍쳐 찾아보기!! 

리눅스 계보는 파도파도 계속 나오는거 같아.. 조금 더 찾아봐야할거 같습니다!
폰 노이만 아키텍쳐는 아직까지도 이름이 나오는 걸 봐서 중요할거 같아 정리했습니다!
다시 정리해야하지만.. 일단 알게된 부분까지 적었습니다!

리눅스 (Linux)

• 오픈소스 운영 체제로, 누구나 무료로 사용하고, 수정하고, 배포할 수 있습니다.
• UNIX 계열 운영 체제로, 다양한 배포판이 존재합니다 (예: Ubuntu, Fedora, Debian 등).
• 서버, 슈퍼컴퓨터, 임베디드 시스템 등 다양한 분야에서 사용되며, 개발자들에게 인기가 많습니다.
• 안정성, 보안성, 유연성이 높아 기업 시스템에서도 널리 사용됩니다.

윈도우 (Windows)

• 마이크로소프트(Microsoft)에서 개발한 운영 체제로, 라이선스가 필요합니다.
• 사용자 친화적인 GUI로 대중적인 인기를 얻었으며, 개인용 컴퓨터의 대부분에 설치되어 있습니다.
• 넓은 사용자 베이스로 인해 다양한 소프트웨어 및 하드웨어와 호환성이 높습니다.
• 게임 및 일반 사용자들에게 인기가 높으나, 서버 환경에서는 보안 및 안정성 면에서 약점이 있을 수 있습니다.

맥 (Mac)

• 애플(Apple)에서 개발한 운영 체제로, 라이선스가 필요하며 애플 하드웨어에서만 실행됩니다.
• UNIX 계열 운영 체제로 BSD를 기반으로 하며, 안정성과 보안성이 높습니다.
• 사용자 친화적인 디자인과 함께 고급 하드웨어와의 완벽한 호환성이 특징입니다.
• 크리에이터, 디자이너, 개발자들에게 인기가 많으며, 높은 품질의 멀티미디어 작업에 적합합니다.

폰 노이만 아키텍처(Von Neumann architecture)는 1945년에 존 폰 노이만(John von Neumann)이 제안한 컴퓨터 구조로, 현대 컴퓨터 아키텍처의 기본적인 원리를 제공합니다. 폰 노이만 아키텍처는 아래와 같은 주요 구성요소로 이루어져 있습니다.

1. 메모리 (Memory): 프로그램 코드와 데이터를 저장합니다. 폰 노이만 아키텍처의 핵심 특징 중 하나는 프로그램 코드와 데이터가 동일한 메모리 공간에 저장된다는 점입니다. 이를 'Stored Program Concept'이라고도 합니다.
2. 처리 장치 (Processing Unit): 처리 장치는 두 가지 하위 구성 요소로 나뉩니다.
   • 산술 논리 연산 장치 (ALU, Arithmetic Logic Unit): 산술 및 논리 연산을 수행합니다.
   • 레지스터 (Registers): 명령어와 데이터를 임시로 저장하는 작은 메모리 공간입니다.
3. 제어 장치 (Control Unit): 제어 장치는 메모리로부터 명령어를 가져와서 해석하고 실행하는 역할을 합니다. 또한 ALU와 다른 장치 간의 데이터 흐름을 조정합니다.
4. 입력 장치 (Input Devices): 사용자로부터 정보를 받아들이는 장치입니다. 예를 들어 키보드, 마우스 등이 있습니다.
5. 출력 장치 (Output Devices): 처리된 결과를 사용자에게 전달하는 장치입니다. 예를 들어 모니터, 프린터 등이 있습니다.