0. 들어가며JPA를 활용하여 애플리케이션을 개발하다 보면 동시성 문제를 해결하기 위해 낙관적 락(Optimistic Lock)을 적용하는 경우가 있습니다. @Version 애노테이션을 사용하면 간단하게 해결되는 것처럼 보이지만, 흔히 낙관적 락을 "락을 걸지 않는다"고 표현하기 때문에 실제로 MySQL에서 어떻게 동작하는지 궁금해졌습니다. MySQL에서 UPDATE 문을 실행할 때는 반드시 락을 획득해야 하는데, 그렇다면 JPA의 낙관적 락은 어떻게 "락 없이" 동작하는 것일까요? 이에 대한 궁금증을 해결하기 위해 찾아본 내용을 정리해보았습니다. 결론적으로, JPA의 낙관적 락은 애플리케이션 차원에서 제공하는 충돌 감지 메커니즘이며, MySQL에서는 UPDATE 수행 시 실제로 락을 거는 것이 맞습니다..

0. 문제상황 🤔 Spring Data JPA를 사용하다가 다음과 같은 상황이 있었습니다. A 라는 엔티티가 B 라는 엔티티를 필드로 가지고 있는데 A를 찾기 위해 B 조건을 걸고 싶었던 것이죠. 원래 같았으면 findByB(B b) 와 같은 메서드를 Spring Data JPA를 사용해 추가했을 텐데 제약사항때문에 findByBId(Long id)와 같이 B의 Id 값을 통해 불러오고 싶었습니다. 근데 왠걸 findByBId(Long id)를 호출하고 쿼리를 확인해보았더니 join문이 끼어있더군요. 이런 상황이 왜 벌어졌는지 알아보았고, 이를 알아본 내용을 정리하려합니다. 1. 테스트 해보기❗️ 우선 상황을 가정해보도록 하겠습니다. 아래와 같이 Member 엔티티와 Team 엔티티가 있다고 생각해봅시다..

0. 들어가며 🏃🏻‍♂️ 이번 글에서는 JPA를 사용할 때 중요한 개념인 N + 1 문제에 대해 알아보려합니다. N + 1 문제는 JPA를 처음 공부할 때부터 중요하다고 들었고, 이에 대한 해결법 역시 대략적으로 알고있다고 생각했습니다. 그런데 막상 실제 프로젝트에서 엔티티가 여러 OneToMany, ManyToOne 필드들을 가지게되고 서로 얽혀있다보니 이를 다루는 방법을 잘모르겠어서 애를 먹은 경험을 했습니다. 또한 N + 1 문제를 해결하기 위해 사용하는 방법들이 어떤 쿼리를 날리길래 해당 문제를 해결하는지, 어떤 방식으로 동작하는지에 대해서도 모르고 사용한다는 생각이 강하게 들었습니다. 이를 위해 N + 1 문제에 대해 조금 더 깊게 알아보는 시간을 가져보았고, 이를 정리해보려합니다. 결론부터 말..