상태 변경 배치를 Spring Batch를 통해 만들었고 멀티쓰레드로 처리하는 과정에서 데드락이 발생해서 문제의 원인을 파악해보려고 한다. 1. 문제가 발생하는 상황 SELECT * FROM A a JOIN B b ON a.id = b.a_id WHERE a.col1 = 'A' a.col2 = 'B' a.col3 = 'C' FOR UPDATE 문제되는 쿼리의 구조는 위와 같다. A 테이블의 col1, col2, col3 컬럼은 인덱스가 생성된 상태이고 B 테이블의 a_id에는 인덱스가 생성되지 않은 상태이다. 아래와 같이 실행계획으로 분석해보았을 때 A 테이블은 인덱스를 통해 검색되지만, B 테이블(아래줄)은 풀스캔이 진행되고 있었다. B 테이블의 a_id 컬럼에 인덱스가 없었기 때문에 풀스캔이 발생하는..
1. Execution Context 스프링 배치에서는 Execution Context를 통해 데이터를 공유할 수 있으며 Execution Context는 Job 전체에 유지되는 Job Execution Context와 각 Step에서만 유지되는 Step Execution 으로 구분할 수 있다. Job Execution Context 는 각 Step이 종료되는 시점에 업데이트 Step Execution Context 는 각 Tasklet? Chunk? 가 종료되는 시점에 업데이트 Step 간의 데이터를 공유하기 위해서는 Job 단위로 데이터가 유지되어야 하기 때문에 Job Execution Context를 사용해야한다. 2. ExecutionContextPromotionListener Job Contex..
1. 버전관리 메커니즘 Reset 명령어를 정확하게 이해하기 위해서는 깃이 파일의 버전을 어떻게 관리하는지 이해가 필요하다. 깃은 관리 파일을 Working Directory, Index, HEAD 3가지 영역(?)으로 관리한다. Working Directory = 개발자의 작업공간(워크스페이스) INDEX(Staging Area) = 체크아웃 이후 파일을 변경하여 커밋의 대상이 파일이 모이는 공간 HEAD = 현재 브랜치를 가리키는 포인터이며, 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킨다 쉽게 말하자면 개발자가 코드를 변경하는 곳이 Working Directory, 코드를 변경하여 커밋의 대상이 되는 파일이 모이는 Index, Index에 있는 파일을 커밋하면 저장되는 곳이 HEAD 이..
신규 프로젝트를 진행하면서 오랜만에 logback 설정을 진행해서 간단한 개념과 사용법에 대해서만 정리를 하려고 한다. 해당 포스팅은 springboot 3.1.2, logback 1.4.8 버전에서 작성되었다. 1. Logback Logback이란 스프링부트에서 로그 관리를 위해 SL4FJ를 구현한 구현체이다. 참고로 SL4FJ란 로깅을 위한 추상화된 인터페이스이다. 2. 설정방법 스프링부트에서 resources 폴더 안의 logback-spring.xml 파일을 읽어서 로깅 관련된 설정을 하는데 만약 해당 위치에 파일이 존재하지 않는다면 application.yml의 파일을 읽어서 처리를 진행한다. // 설정.. 로깅을 설정할 때는 기본적으로 xml 파일을 사용하며 configuration 속성을 루..
