들어가며 지난 글에서 JPA가 알아서 동시성 이슈를 해결해주는 모습을 보였지만, 어디까지나 운이라는 결론을 내렸습니다. 이어서 어드민 페이지 동시성 이슈를 직접 해결해보겠습니다. 두 번의 갱신 분실 문제 JPA가 동시성 문제를 파악하고 예외를 던져주는 행위가 운이라고 했는데, 이는 영속성 컨텍스트를 계속 동기화 시켜주는 부분을 제거하면 곧 바로 동시성 문제가 다시 발생하기 때문입니다. 여기서 말하는 동시성 문제란 두 번의 갱신 분실 문제를 뜻하는데, 아래와 같이 3가지 상황이 존재합니다. 최초 커밋만 인정하기 : 첫 번째로 커밋한 트랜잭션의 변경 사항만 반영하고, 마지막 트랜잭션의 변경 사항은 무시한다. 마지막 커밋만 인정하기 : 마지막으로 커밋한 트랜잭션의 변경 사항만 반영하고, 첫 번째 트랜잭션의 변..

들어가며 이번 글에서는 팀 프로젝트의 어드민 페이지에서 데이터 수정에 관련한 동시성 이슈를 알아보려고 합니다. 저희 서비스의 관리자 페이지는 유저들에게 직접적으로 보이는 식품 데이터를 생성/수정/삭제할 수 있는 기능을 제공합니다. 선착순 시스템 등과 갑자기 많은 트래픽이 몰리진 않겠지만, 유저와 사료를 파는 브랜드에게 직접적인 영향이 가는 영역이기 때문에 한 번 발생하게 된다면 서비스 운영에 치명적으로 작용할 수 있습니다. 어떤 문제가 발생할까 그렇다면 만약 2명의 어드민이 동시에 하나의 식품을 수정하게 된다면 어떤일이 발생할까요? 아래는 사료 데이터를 수정하는 메서드 2개를 동시에 실행하는 테스트 코드입니다. 저는 처음에 낙관적 락과 비관적 락을 모두 사용하지 않은 상태였기 때문에 두 번의 갱신 분실 ..

개념적 차이 List와 Set은 모두 JCF이다. 당연히 차이도 존재한다. List에는 중복 데이터가 포함될 수 있지만, Set에는 중복 데이터가 포함될 수 없다. List는 삽입 순서를 유지하지만 Set은 유지할 수 있고, 유지하지 않을 수도 있다. Set은 삽입 순서가 유지되지 않을 수 있으므로 인덱스 기반 액세스를 허용하지 않는다. LinkedHashSet과 같이 순서를 유지하는 Set도 있다. List와 Set 성능 비교 JMH(Java Microbench Harness)를 사용해서 List, Set 데이터 구조의 성능을 비교해 보자. 먼저 ListAndSetAddBenchmark 및 ListAndSetContainBenchmark라는 두 개의 클래스를 만든다. 그다음 List 및 Set 데이터 ..

집사의고민 프로젝트에서 JPA를 사용하면서 알아본 Fetch Join시 유의해야 하는 부분들에 대해서 기술해보려고 합니다. 특히나 자주 사용하는 fetch join + on절에 대한 이슈를 모르거나 잘 기억이 나지 않으신다면 이해하고 넘어가는게 좋습니다. 우선 쿼리가 정상적으로 동작하는지와 어떤 쿼리가 발생하는지를 알아보기 위해 간단한 테스트 코드를 작성해보았습니다. PetFoodRepositoryImplTest @DataJpaTest @Import(QueryDslTestConfig.class) @Sql(scripts = {"classpath:truncate.sql", "classpath:data.sql"}) @AutoConfigureTestDatabase(replace = AutoConfigureTes..