교착 상태(deadlock) 는 두 개 이상의 작업이 서로 상대방의 작업이 끝나기만을 기다리고 있어 결과적으로 아무것도 완료되지 못하는 상태를 의미합니다. 가령, A 프로세스가 자원 A를 가지고 자원 B를 필요로 합니다. 그리고, B 프로세스는 자원 B를 가지고 자원 A가 필요할 때 두 개의 프로세스는 교착 상태에 빠져 어느 작업도 진행할 수 없는 상황이 됩니다.교착 상태가 발생하는 조건을 알고 계신가요? 🤔4가지 조건(상호 배제, 점유 대기, 비선점, 원형 대기)이 모두 만족하는 경우, 교착 상태에 빠질 수 있습니다.상호 배제(mutual exclusion) 는 한 프로세스가 사용하는 자원을 다른 프로세스가 사용할 수 없는 경우를 의미합니다.점유 대기(hold and wait) 는 자원을 할당받은 상..

문제의 시작은 서버 배포 후 서비스를 운영하며 새로운 기능을 만들고 있던 때 부터인 것으로 확인되었다.첫번째 상황으로는 추가 기능인 댓글&대댓글을 개발 서버에만 적용을 하고 배포 서버에는 적용을 하지 않았기 때문에 배포 DB에 comment 관련 테이블이 존재하지 않다는 것이다.이 부분은 flyway로 script.sql에 comment 테이블이 존재하지 않을 시 생성하도록 명령어를 작성해 놓았기 때문에 문제 해결 두번째 상황으로는 member 테이블에 role 컬럼 타입 불일치 문제가 발견되었다.이 또한 서버 배포 후 다른 팀원이 role 이라는 enum 클래스에 Converter 를 적용하게 되면서 발생한 것이다.이를 해결하기 위해서는 아래와 같이 수정해야한다.@Converterpublic class..

Redis가 단일 스레드(single-threaded)로 설계된 이유는 주로 성능 최적화, 복잡성 감소, 그리고 데이터 일관성을 유지에 있습니다.단일 스레드 모델은 멀티스레드 모델에 비해 설계와 구현이 상대적으로 간단합니다. 멀티스레드 환경에서는 동시성 문제(레이스 컨디션, 데드락 등)를 처리하기 위해 복잡한 동기화 메커니즘이 필요하지만, 단일 스레드 환경에서는 이런 문제를 자연스럽게 회피할 수 있습니다. 동시에 여러 스레드가 동일한 데이터를 수정하려고 할 때 발생할 수 있는 데이터 불일치 문제를 방지합니다. 모든 명령어가 순차적으로 처리되기 때문에, 복잡한 락(lock) 메커니즘 없이도 데이터의 일관성을 자연스럽게 유지할 수 있습니다.Redis는 주로 메모리 내에서 빠르게 수행되는 I/O 작업을 처리하..

JWT(Json Web Token) 은 통신 정보를 JSON 형식을 사용하여 안전하게 전송하기 위해 사용됩니다. JWT는 토큰 자체에 정보가 포함되어 있는 클레임 기반 토큰입니다. 일반적인 애플리케이션에서 JWT는 주로 인증과 인가를 구현하기 위해 사용됩니다.  JWT는 헤더, 페이로드, 시그니처로 구분됩니다. 헤더에는 토큰의 암호화 알고리즘이나 타입을 가지며, 페이로드에는 데이터(만료일, 사용자 정보 등)을 가집니다. 시그니처는 헤더와 페이로드가 변조되지 않았는지 판단하기 위해 사용되는데요. 헤더와 페이로드를 비밀 키를 사용하여 헤더에 명시된 암호화 알고리즘으로 암호화하여 시그니처가 만들어집니다. JWT를 사용하여 인가를 구현하는 경우, 클레임 기반 토큰의 특성 덕분에 세션 기반 인증에 비해서 사용자 ..

프로젝트 진행 중 불필요한 연관관계를 끊고, 조회 성능을 향상시키기 위해 Post 테이블에 member 정보에 대한 컬럼을 추가했었다. 컬럼을 추가할 생각을 가졌을 때에는 당장 연관관계보다의 장점만을 생각하면서 진행하였지만 막상 적용하고 나서 보니 단점도 보이기에 이 글을 적게되었다. 단점으로는 데이터 일관성이 있겠다.닉네임이 member_A 인 회원이 글을 작성하면 해당 post의 작성자 닉네임은 당연하게도 member_A 이다.하지만 이후 member_A가 닉네임을 member_B로 수정을 한 후에도 이전 post의 작성자 닉네임은 member_A 이다.여기까지는 예상을 했던 상황이고 그저 post 수정 시 새로 업데이트 해주면 되겠다 생각을 했다.하지만 또 다른 회원이 member_A로 닉네임을 수..

첫 번째 문제 발생flyway로 DB 스키마 변경하는 테스트를 로컬에서 마치고, 개발 서버에 적용을 했을 때 발생한 오류이다.org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]:Failed to initialize dependency 'flyway' of LoadTimeWeaverAware bean 'entityManagerFactory': Error creatin..

Flyway로 생성된 flyway_schema_history 테이블에는 스키마 변경 내역이 저장되는데 만약 V2 스크립트 파일을 마이그레이션하다가 오류가 발생하게 된다면, flyway_schema_history 테이블에는 V2에 대한 실패 내역이 저장되게 된다. 이후에 실패한 원인을 찾아 V2 스크립트 파일의 명령어를 수정하고 다시 실행한다 해도 이미 V2에 대한 실패 내역이 남아있기 때문에 해당 버전은 flyway가 실행하지 않는다. 그렇다면 수정한 코드로 V3를 새로 만들어서 실행해야하느냐? 물론 이 방식도 존재하지만 간단한 오류를 고치기 위해 항상 새로운 버전을 생성해야하는 것은 번거로운 방법이라 볼 수 있다. 그러면 기존에 에러나 스크립트 파일을 수정한 뒤에 어떻게 다시 적용할 수 있을까?해결방법..

이전 글에서도 말했듯이 이번 포스팅에서는 로컬 데이터베이스에 스키마 구조를 변경해보고 flyway를 통해 제대로 적용이 되는지 확인해보겠다.Entity 구조 변경ddl-auto: validate 로 설정해뒀기 때문에 Entity와 DB 테이블의 구조가 같은지 비교하고 유효성 검사를 위해 앞으로 변경할 DB 스키마 구조에 맞게 entity도 변경해줘야 한다. Member Entity와 연관관계 매핑 되있던 것을 끊고 회원 아이디, 이메일, 닉네임 컬럼을 추가한다. 현재 CodePost, TILPost 테이블 두 개가 존재하기 때문에 각 Entity 구조를 아래와 같이 변경하면 되겠다.연관관계와 관련된 로직들의 수정 코드는 따로 작성하지는 않겠다.// member 컬럼 삭제// @ManyToOne(fetch..