@Transactional 메소드 내에서 @Transactional(propagation = Propagation.REQUIRED_NEW) 메소드를 실행하게되면 어떤 일이 발생할까

트랜잭셔널 메소드에서 새로운 트랜잭션을 시작하면 어떤일이 발생하는지 알아보자.

1. 애플리케이션 시작 시 작업

1-1. 트랜잭션 관리자 등록

• 애플리케이션 시작 시 트랜잭션 관리자가 등록된다.
• 트랜잭션 전파 정책(Propagation)을 처리할 수 있도록 AOP 프록시가 생성된다.

1-2. AOP 프록시 생성

• @Transactional이 적용된 메소드에 대해 프록시가 생성된다.
• 각각의 메소드가 호출될 때 전파 정책을 해석하도록 설정된다.

2. 부모 매소드 실행(@Transactional, REQUIRED 전파 정책)

2-1. 트랜잭션 시작

• 부모 메소드가 호출되면 프록시가 트랜잭션 관리자를 통해 트랜잭션을 시작
• 트랜잭션 전파 정책 Propagation.REQUEIRED의 기본 동작에 따라 기존 트랜잭션이 없으면 새 트랜잭션을 시작.
• 데이터베이스 연결이 확보되고, auto-commit이 비활성화됨

2-2. 비지니스 로직 실행 중 자식 메소드 호출

• 부모 메소드 내에서 Propagation.REQUIRED_NEW가 적용된 자식 메소드가 호출됨.

3.자식 메소드 실행(@Transactional, Propagation.REQUIRED_NEW)

3-1. 부모 트랜잭션 일시 중단

• 자식 메소드가 호출되면 부모 트랜잭션이 일시중단 상태로 변경됨.
• 일시 중단된 트랜잭션은 컨텍스트에 보관되며, 자식 메소드가 끝날때까지 대기.

3-2. 새로운 트랜잭션 시작

• 자식 메소드는 항상 별도의 트랜잭션에서 실행
  • 트랜잭션 관리자가 새로운 데이터베이스 연결을 확보하거나 기존 연결을 재사용 하여 별도 트랜잭션을 시작.
  • 새로운 트랜잭션은 부모 트랜잭션과 독립적으로 커밋 또는 롤백될 수 있다.

3-3. 비지니스 로직 실행

• 자식 메소드의 비지니스 로직이 새로운 트랜잭션 내에서 실행됨.
• 데이터베이스 작업은 자식 트랜잭션의 컨텍스트에서만 적용됨.

3-4. 자식메소드 종료

• 자식 메소드 실행이 끝나면 아래와 같은 동작 발생
  • 정상종료시, 커밋
  • 예외 발생시 자식 트랜잭션롤백

4. 부모 메소드 재개

4-1. 부모 트랜잭션 복구

• 자식 메소드 실행이 끝난 후, 무보 트랜잭션이 일시중단 상태에서 복구됨.
• 부모 트랜잭션은 자식 트랜잭션과는 독립적으로 계속 진행됨.

4-2. 부모 메소드 비지니스 로직 실행(남은 작업)

• 부모 메소드의 나머지 비지니스 로직 실행.
• 데이터베이스 작업은 부모 트랜잭션 컨텍스트에 반영.

4-3 부모 메소드 종료

• 부모 메소드 종료되면 아래와 같은 동작 발생
  • 정상 종료시 커밋
  • 예외 발생시 부모 트랜잭션 롤백

5. 특이 케이스

5-1. 자식 트랜잭션 커밋 후 부모 트랜잭션 롤백

• 부모 트랜잭션이 나중에 롤백 되더라도 자신 트랜잭션은 독립적으로 커밋 되었기 때문에 영향을 받지 않는다.

5-2. 자식 트랜잭션 롤백 후 부모 트랜잭션 정상 종료

• 자식 트랜잭션이 실패하면 부모 트랜잭션은 이를 감지할 수 없다.
  • 단, 예외를 명시적으로 처리한다면 감지시킬 수 있다.
  • 부모 트랜잭션은 독립적으로 커밋 또는 롤백된다.

정리:

1. 부모 메소드(@Transactional, Propagation.REQUIRED)가 호출되며 트랜잭션이 시작됨.
2. 자식 메소드(@Transactional, Propagation.REQUIRED_NEW)가 호출되면 부모 트랜잭션 일시중단.
3. 자식 메소드는 새로운 트랜잭션에서 실행되며 독립적으로 커밋 또는 롤백됨
4. 자식 메소드 실행 후, 부모 트랜잭션이 북구되어 남은 로직 실행
5. 자식과 부모 트랜잭션은 서로 독립정이며, 서로의 성공 여부에 영향을 주지 않음.

이런 구조로 트랜잭션간의 독립성이 보장되며, 필요 시점에 새로운 트랜잭션을 생성해 데이터 무결성을 관리하는데 도움이 된다.

@Transactional 어노테이션이 있는메소드, 스프링 시작부터 메소드 시작까지의 작업

@Transactional 어노테이션이 있는 메소드가 실행될때 어떤 일이 일아날까.
스프링 시작부터 메소드가 실행되고 종료될때까지 어떤일 일어나는지 알아보자.

1.어플리케이션 시작시 작업

1-1.트랜잭션 관리자 등록

• Spring Boot는 자동 설정(Auto Configuration)을 통해 적절한 트랜잭션 관리자를 등록한다.
  • 에를들어, JPA를 사용하는 경우 JpaTransactionManager를 기본으로 등록한다.
• 이 관리자는 트랜잭션의 시작, 커밋, 롤백 등을 담당함.

1-2.AOP 프록시 생성

• @EnableTransactionManagement 또는 자동 설정에 의애 트랜잭션 메소드가 AOP프록시로 감싸진다.
• 스프링은 빈 스캐닝 중 @Transactional이 붙은 메소드를 확인하고, 해당 메소드가 실행될 때 트랜잭션 관리가 적용되도록 프록시 객체를 생성한다.
  • 기본적으로 CGLIB 또는 JDK 동적 프록시를 사용한다.

2.메소드 실행 시 작업

2-1.프록시를 통한 메소드 호출

• 트랜잭션 메소드를 호출하면 실제 메소드를 실행하기 전에 프록시 객체가 인터셉트한다.
• 프록시는 트랜잭션 설정과 관리작업을 수행한 후 실제 메소드를 호출한다.

2-2.트랜잭션 동작 정의 확인

• 프록시는 메소드에 선언된 @Transactional송성을 확인한다.
  • 트랜잭션 전파(Porpagation)
  • 격리수준(Isolation Level)
  • 읽기 전용(Read-only)
  • Timeout
  • 롤백 정책(Rollback Rules)

2-3.트랜잭션 시작

• 트랜잭션 관리자는 트랜잭션을 시작한다.
  • 트랜잭션 전파 전책에 따라 새 트랜잭션을 생성하거나 기존 트랜잭션에 참여한다.
• 데이터베이스 커넥션을 확보하고(필요시), auto-commit이 비 활성화 된다.

3.실제 메소드 실행

3-1.비지니스 로직 실행

• 트랜잭션 컨텍스트 내에서 실제 메소드가 실행됨.
• 데이터베이스의 CRUD 작업이 발생하면, 변경 사항은 트랜잭션 컨텍스트 내에 보류됨

3-2.예외 처리

• 메소드 실행 중 예외가 발생하면, 프록시는 롤백 정책을 참조하여 트랜잭션 롤백 여부를 결정.
  • 기본적으로 RuntimeException 과 Error 가 발생하면 롤백됨.
  • checked exception은 명시적으로 롤백 설정이 없으면 커밋됨.

4.메소드 실행 완료 후 작업

4-1. 트랜잭션 커밋 또는 롤백

• 메소드 실행이 성공적으로 끝나면 트랜잭션 관리자는 트랜잭션을 커밋한다.
  • 데이터베이스 변경 사항이 확정되고, 커넥션이 반환된다.
• 예외가 발생한 경우 롤백 작업이 수행된다.
  • 변경된 데이터는 폐기되며, 트랜잭션이 중단됨.

4-2.리소스 정리

• 트랜잭션이 종료되면 사용된 데이터베이스 커넥션 및 기타 리소스가 pool로 반환된다.
• 트랜잭션 컨텍스트와 관련된 쓰레드 로컬 데이터가 정리된다.

5.애플리케이션 종료 시 작업

• 트랜잭션 관리자는 애플리케이션 종료 시 등록된 리소스를 정리하며, 사용중인 데이터베이스 연결이나 트랜잭션 관련 매니저를 닫는다.

정리

1. 애플리케이션 시작 : 트랜잭션 관리자 설정, AOP프록시 생성
2. 메소드 호출시 :
   • 프록시가 트랜잭션을 시작, 트랜잭션 속성 확인
   • 메소드를 실행하며 예외 여부에 따라 커밋 또를 롤백을 결정
3. 메소드 실행 후 : 트랜잭션이 종료되고 리소스 반환
4. 애플리케이션 종료시 : 트랜잭션 관련 리소스 정리

스프링 부트 어플리케이션이 실행되면 어떤 일들이 일어나는가.

Spring Boot Application이 시직되면 내부에서 일어나는 일에 대해 정리한다.

1.JVM 및 Main 메서드 시작

• JVM 이 애플리케이션을 실행하며 main메서드를 호출
• Spring Boot 애플리케이션은 @SpringBootApplication 어노테이션이 붙은 클래스의 main메서드를 시작점으로 잡는다.

2.SpringApplication 초기화

• SpringApplication.run() 메서드가 호출되며 스프링 애플리케이션 컨텍스트가 초기화됨
• 주요 작업
  • 애플리케이션 타입 결정(Servlet, Reactive, None)
  • 배너 출력 여부 설정
  • 기본 프로퍼티 및 환경 로딩

3.Environment 생성 및 설정

• Environment 객체가 생성되어 시스템 속성, 환경 변수, 프로파일 등이로그됨
• 외부설정(ex: application.properties, application.yml)이 읽혀지고 환경 변수와 병합됨.

4.Application Context 생성

• Spring Boot 는 실행 모드에 따라 적절한 컨텍스트를 선택함.
  • AnnotationConfigServletWebserverApplictionContext (웹 어플리케이션)
  • AnnotationConfigReactiveWebServerApplicationContext (리액티브 어플리케이션)
  • AnnotationConfigApplictionContext (비 웹 어플리케이션)
• 이 컨택스트는 어플리케이션의 모든 빈(bean) 및 설정을 관리함

5.CommandLineRunner 및 ApplicationRunner등록

• ApplicationContext 초기화 중에 CommandLineRunner와 ApplicationRunner 인터페이스를 구현한 빈들이 등록됨
• 이 빈들은 애플리캐이션 초기화가 완료된 후 추가 작업을 실행할 수 있음.

6.자동설정(Auto Configuration)

• Spring Boot는 @EnableAutoConfiguration을 통해 여러 자동 설정 클래스(AutoConfiguration)을 활성화함.
• 자동 설정은 클래스 패스 및 환경 변수를 기반으로 애플리케이션에 필요한 빈을 자동으로 구성함.
  • Ex) DB Connection 설정, Web server 설정, Spring Security 설정 등

7.빈(Bean) 등록 및 DI(의존성 주입)

• 스프링 애플리캐이션 컨텍스트 내에서 모등 @Component, @Service. @Repository, @Controller 등의 빈을 스캔하여 등록
• 등록된 빈들 간의 의존성을 주입(생성자, 세터, 필드 기반)
• 프로파일 조건에 따라 특정 빈만 활성화될 수도 있음.

8.내장 웹서버 시작(Optional)

• 웹 어플리케이션인 경우, Spring Boot는 내장된 톰캣, 제티, 언더토우 등을 통해 HTTP서버를 시작
  • HTTP 포트, SSL설정 등이 적용됨.
• 서블릿 컨테이너가 초기화 되고 DispatcherSErvlet이 설정됨.

9.Spring MVC 또는 WebFlux 설정(웹 애플리케이션인경우)

• DispatcherServlet을 통해 요청을 처리하는 기본 매핑을 설정
• HandlerMapping,HandlerAdapter,ViewReolver등을 초기화 하여 웹 요청에 필요한 구성요소를 준비

10.이밴트 발행 및 리스너 실행

• Spring Boot는 애플리케이션 실행 과정에서 여러 이벤트를 발행함.
  • ApplicationStartingEvent
  • ApplicationEnvironmentPreparedEvent
  • ApplicationPreparedEvent
  • ApplicationStartedEvent
  • ApplicationReadyEvent
• 위 이벤트를 통해 특정 시점에 사용자 정의 작업을 실행할 수 있음.

11.애플리케이션 준비 완료

• 애플리케이션 컨택스트 초기화가 완료되고, 모든 빈이 생성되고 초기화됨
• CommandLineRunner 및 ApplicationRunner구현체가 실행됨.
• ApplicationReadyEvent 가 발행되며 애플리케이션이 요청을 처리할 준비가 완료됨

12.애플리케이션 실행 상태 유지

• Spring Boot는 실행 상태를 유지하며 HTTP요청을 대기하거나 비웹 애플리케이션에서는 작업을 지속함.
• 내부적으로 애플리케이션 컨택스트는 필요에 따라 라이프 사이클을 관리함.

13.애플리케이션 종료

• 애플리캐이션 종료시 Spring Boot는 ApplicationContext를 닫으며 빈의 destroy() 메서드 호출 및 리소스 정리를 수행
• ApplicationFailedEvent 가 발행될 경우 애플리케이션 시패를 기록

Spring Boot Application으 LifeCycle에 대해 간략하게 정리 해 보았다.
Spring 기반의 서비스를 운영 / 개발 하는 회사라면 자주 나오는 질문이니 숙지하고 있으면 좋다.
세부 내용까지는 힘들더라도 1~12번 넘버링 되어있는 순서만이라도 기억하면 좋다.

Iterator

컬렉션에 저장된 요소를 읽어오는 방법을 표준화한것.
다음의 메소드를 포함하고있다.

• hasNext() : 읽어올 다음 요소가 있는지 확인하는메소드. 다음 요소가 있다면 true, 없다면 false를 반환
• next(): 다음 데이터를 리턴
• remove() : next()로 읽어온 요소를 제거.

Interface VS Abstract

Abstract class(추상 클래스)

• 클래스 구현 내부에 추상 메서드가 하나 이상 포함되거나 abstract로 정의된 경우.
• Abstract class의 특징
  • new 연산자를 사용하여 객체르 생성할 수 없다.
    • 단일 상속만이 가능하다.
    • Abstract 클래스는 동일한 부모를 가지는 클래스를 묶는 개념으로 상속을 통하여 기능을 확장시키는것이 목적이다.

Interface

• 모든 메소드가 추상 메소드이다.
• Java 8 이후에서는 default 키워드를 이용하면 메소드를 구현할 수 도 있다.
• static final필드만 가질 수 있다.
• new 연산자를 사용하여 객체를 생성할 수 없다.
• 다중상속이 가능하다.
• 구현 객체가 같은 동작을 한다는것을 보장하려는 목적으로 사용된다.

Abstract class와 Interface의 공통점

• 선먼만 있고 구현 내용은 없는 클래스이다.
• 인스턴스화가 불가능하다.
• 상속 / 구현한 클래스를 이용해서 객체를 생성해야한다.

Abstract class와 Interface의 차이점

• Abstract class - 단일상송 / Interface - 다중 상속
• Abstract 의 목적은 상속을 이용하여 기능을 확장시키는 것이다.
• Interface의 목적은 메소드가 구현됨을 보장하는것이다.

WAS의 동작방식

• WAS

  • Web Server와는 다르게 DB조회 등 다양한 로직 처리를 요구하는 동적인 컨텐츠를 담당.
  • 웹 컨테이너, 혹은 서블릿 컨티에너라고 불림.
  • 분산 트랜잭션, 보안, 메시징, 스레드 처리 등의 기능을 처리하는 분산환경에서 사용
  • Tomcat, JBoss 등이 대표직인 WAS이다.

• 동작 방식

  1. Web Server 의 클라이언트의 요청에 맞는 Servlet을 메모리에 올린다.
  2. web.xml에을 참조해 해당 Servlet에 대한 Thread를 생성한다.
  3. HttpServletRequest와 HttpServletResponse 객체를 생성하고 그에 맞는 doGet 또는 doPost 메소드를 호출해 생성된 동적 페이지를 Response 객체에 담아 WAS에 전달한다. ex) doGet(HttpServletRequest request, HttpServletResponse response)가 리턴하는 Response 객체를 WAS에 전달.
  4. WAS는 HttpResponse 형태로 바꾸어 WebServer에 전달하고 생성된 스레드와 HttpServletRequest, HttpServletResponse 객체를 제거한다.

  참고자료 : https://new-be.tistory.com/3

JVM(Java)의 메모리 구조

JVM의 메모리 구조는 힙 메모리 / 비 힙메모리 / 기타 세가지로 나뉜다.

힙 메모리(Heap memory)

• 힙영역은 자바 클래스의 인스턴스와 배열이 할당되는 영역
• Run Time시 데이터를 저장.
• JVM이 시작될때 생성되어 어플리케이션 실행동안 크기가 변동된다.
• 힙영역의 크기는 -Xms VM option 으로 지정된다.
• 힙영역의 크기는 가비지 컬렉션의 전략에따라 고정 / 변동 적으로 설정이 가능하다.
• 힙영역의 퇴대크기는 Xms option으로 설정한다. 디폴트는 64MB이다.
• 힙영역은 물리적으로 nursery(young space / young generation) 파트와 old space(old generation) 두 부분으로 나뉜다.
  • nursery : 새로운 객체 할당을 위해 확보된 공간. 이곳이 가득차면 young collection을 실행하여 가비지를 수집한다. young collection은 nursery에 어느정도 모문 객체를 old space로 이동시켜서 nursery에 더 많은 객체를 할당할 수 있도록 한다. 이런 가비지 컬렉션을 Minor GC라고한다.

비 힙 메모리(Non-Heap memory)

• Heap과 마찬가지로 JVM시작시 생성된다.
• 런타임 상수 풀, 필드 및 메소드 데이터같은 크래스별 구조와 메소드 및 생성자에 대한 코드, 나부 문자열이 저장된다.
• 디폴트 크기는 64M, XX:MaxPermSize VM Option을 이용해서 변경 가능

기타 메모리

• JVM 자체의 코드와 내부 구조, 로드된 프로피일러 에이전트 코드와 데이터 등을 저장하기 위해 사용.

침고 : https://shinjekim.github.io/java/2020/01/06/%EC%9E%90%EB%B0%94%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EA%B5%AC%EC%A1%B0/

DB 정규화

정규화란: 데이터를 저장할때 불필요한 데이터를 제거하고, CRUD시 발생할 수 있는 각종 사이드이팩틀르 방지한다.

1차 정규화 : 도메인 원자성을 확보 ( 한 컬럼이 하나의 값만을 가진다.)
2차 정규화 : 부분적 함수 종속 제거(즉, 완전 함수적 종속으로 만든다.)
3차 정규화 : 이행적 함수종속 제거 (즉, 키 이외의 다른 값이 다른 컬럼을 결정할 수 없다.)
BCNF: 모든 결정자가 후보키 집합에 속하게 만든다.

MVC란?

MVC : Model, View, Controller

• 어릎리케이션 / 프로젝트를 구성할때 구성요소를 모델 / 뷰 / 컨트롤러 세가지로 구분한 패턴.

  Model : 어플리케이션의 정보, 데이터를 나타냄. DATA / 정보의 가공을 책임지는 컴포넌트.

• Model이 지켜야하는 규칙

  1. 사용자가 편집하길 원하는 모든 데이터를 가지고있어야한다.
  2. 뷰나 컨트롤러에 대해서 어떤 정보도 알 필요가없다.
  3. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야한다.

  View : 사용자와의 인터페이스를 담당하는 컴포넌트.

• View가 지켜야하는 규칙

  1. 모델이 가진 정보를 따로 저장해서는 안된다.
  2. 모델이나 컨트롤러와 같이 다른 구성요소들을 알 필요가 없다.
  3. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야한다.

Controller: 모델과 뷰를 연결해주는 컨트롤러 역할

• Controller가 지켜야하는 규칙
  1. 모델 / 뷰에 대해 알고있어야한다.
  2. 모델 / 뷰의 변경을 모니터링해야한다.

MVC 패턴의 장점

• 각각의 역할을 정한 컴포넌트를 만들어 각각의 역할에 집중할 수 있도록한다.
• 각각의 역할에 집중하고있기때문에 유지보수성 / 확장성 / 유연성이 증가한다.

Java Collection framework interface의 특징

 - List : 순서가 있는 데이터의 집합, 데이터의 중복을 허용
- Set : 순서가 없는 데이터의 집합, 데이터의 중복을 허용하지 않는다.
- Map : key / value의 쌍으로 이루어진 데이터의 집합. 순서는 유지되지 ㅇ낳으며 키는 중복ㅇ르 허용하지 않고 값은 중복을 허용한다.