[🌱 JPA 방탈출 예약 대기] 초록 미션 제출합니다.

README.md

@@ -94,19 +94,36 @@
 
 - [x] 이미 다른 사용자에 의해 예약된 슬롯(날짜+시간+테마)에 대기를 신청할 수 있다.
     - [x] 예약 대기 테이블 추가
-    - [x] 예약이 존재하는 예약을 등록할 때 다른 사용자(이름)이면 대가 순번으로 넘어가고, 아니면(동일한 사용자) 예외를 던진다.
+    - [x] 예약이 존재하는 슬롯을 등록할 때 다른 사용자(이름)이면 대기 순번으로 넘어가고, 아니면(동일한 사용자) 예외를 던진다.
 - [x] 같은 슬롯에 대한 대기는 신청 순서대로 순번이 부여된다.
 - [x] 같은 사용자가 같은 슬롯에 중복 대기할 수 없다.
 - [x] 사용자는 본인의 대기를 취소할 수 있다.
 
-<!--
-- [ ] 예약이 취소될 때 대기 순번의 1번이 예약으로 바뀐다. (사이클2)
-  - 예약 취소 -> 예약 대기 슬롯 확인 -> 대기 순번의 1번을 예약 추가 -> 대기 순번 1번 삭제 (사이클2)
+- [x] 예약이 취소될 때 대기 순번의 1번이 예약으로 바뀐다.
+1. 취소할 예약을 조회한다.
+2. 취소할 예약과 같은 슬롯의 대기 1번을 조회한다.
+3. 기존 예약을 삭제한다.
+4. 대기 1번이 있으면 예약으로 생성한다.
+5. 승격된 대기를 삭제한다.
 
-- [ ] 예약을 변경할 때 예약이 존재하는 경우 예약된 슬롯에 대기를 신청할 수 있다. (사이클2)
-  - [ ] 변경된 예약의 가장 빠른 대기 순번이 예약된다. (사이클2)
--->
+### 예약 대기 승인 정책
 
+- [x] 자동 전환 방식을 선택한다.
+    - 예약 취소 시 같은 슬롯의 대기 1번을 즉시 예약으로 승격한다.
+    - 별도 관리자 승인 화면 없이 사용자의 취소 흐름 안에서 빈 슬롯을 바로 채워 사용자 대기 경험을 단순하게 유지한다.
+- [x] 대기 승격 후 남은 대기 순번은 조회 시 생성 시각과 ID 기준으로 다시 계산한다.
+- [x] 대기 취소 후 남은 대기 순번은 조회 시 생성 시각과 ID 기준으로 다시 계산한다.
+
+### 트랜잭션 경계
+
+- [x] 예약 취소, 대기 1번의 예약 승격, 승격된 대기 삭제는 하나의 상태 전이이므로 같은 트랜잭션으로 묶는다.
+- [x] 승격 중 중간 실패가 발생하면 기존 예약 삭제와 승격 예약 생성이 함께 롤백되는지 테스트로 확인한다.
+- [x] 예약 생성에서 예약 저장 실패 후 대기 저장으로 전환되는 흐름은 예약 저장과 대기 저장의 트랜잭션을 분리한다.
+
+### API 확인 시나리오
+
+- [x] `DELETE /reservations/{id}?name={name}` 요청 후 대기 1번이 `RESERVED`로 조회되고 남은 대기자의 `waitingOrder`가 1로 재정렬된다.
+- [x] `DELETE /waitlists/{id}?name={name}` 요청 후 남은 대기자의 `waitingOrder`가 1, 2로 재정렬된다.
 ---
 
 ### 내 예약 목록

build.gradle

@@ -13,15 +13,17 @@ java {
 }
 
 repositories {
+    maven { url 'https://jitpack.io' }
     mavenCentral()
 }
 
 dependencies {
     implementation 'org.springframework.boot:spring-boot-starter'
     implementation 'org.springframework.boot:spring-boot-starter-web'
     implementation 'org.springframework.boot:spring-boot-starter-validation'
-    implementation 'org.springframework.boot:spring-boot-starter-jdbc'
+    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
     implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
+    implementation 'com.github.Uechann:my-sql-logger:v1.0.1'
     runtimeOnly 'com.h2database:h2'
 
     testImplementation 'org.springframework.boot:spring-boot-starter-test'

docs/api명세.md

@@ -43,6 +43,14 @@ Content-Type: application/json
 }
 
 ### 생성, 대기 응답
+#### status, waitingOrder 해석 규칙
+status는 예약 신청 결과를 나타낸다.
+
+- RESERVED: 예약이 확정된 상태이며, 대기 순번이 없으므로 waitingOrder는 null이다.
+- WAITING: 예약 대기 상태이다.
+- POST /reservations 생성 응답에서는 WAITING 상태여도 waitingOrder가 null일 수 있다. 이 값은 대기 순번이 없다가 아니라 생성 응답에서 대기 순번을 제공하지 않는다라는 의미이다.
+- 클라이언트가 대기 순번이 필요한 경우 GET /reservations?name={name} 조회 응답에서 확인한다.
+
 HTTP/1.1 201 Created
 Content-Type: application/json
 
@@ -157,12 +165,14 @@ Content-Type: application/json
 
 ```http request
 ### 삭제 요청
-DELETE /waitlists/{id} HTTP/1.1
+DELETE /waitlists/{id}?name=브라운 HTTP/1.1
 
 ### 삭제 응답
 HTTP/1.1 204 No Content
 ```
 
+- 대기 취소 후 같은 슬롯에 남은 대기 순번은 생성 시각과 ID 기준으로 재계산된다.
+
 ### 테마 API
 
 ```http request
@@ -317,6 +327,9 @@ DELETE /reservations/{id}?name=브라운 HTTP/1.1
 HTTP/1.1 204 No Content
 ```
 
+- 예약 취소 시 같은 슬롯의 대기 1번이 자동으로 예약 승격된다.
+- 승격된 대기는 대기 목록에서 제거되고, 같은 슬롯에 남은 대기 순번은 생성 시각과 ID 기준으로 재계산된다.
+
 ### 에러 응답 명세
 
 | 상황                                     | 상태 코드                     |

docs/jpa/DIRTY_CHECKING.md

@@ -0,0 +1,40 @@
+## 관찰: DirtyChecking
+
+### 시도한 코드
+
+Theme객체를 DB에 저장한 뒤, Theme의 changeName() 이라는 메서드를 사용하여
+객체 내부의 속성을 바꾸고 flush()를 호출함.
+
+### 예측한 SQL/동작
+
+Dirty Checking을 통해서 Hibernate가 영속성 컨텍스트에 올라온 Theme이라는 객체를
+보고있다가 update 쿼리를 날려서 변경된 객체 내부 속성을 DB에 함께 반영함.
+
+```sql
+UPDATE theme
+SET description,
+    name,
+    thumbnail_image_url
+WHERE id = ?
+```
+
+### 실제 SQL/동작
+
+```sql
+update theme
+set description=?,
+    name=?,
+    thumbnail_image_url=?
+where id = ?
+```
+
+### 왜 그런가
+
+Hibernate는 영속성 컨텍스트에 올라온 객체를 계속 보다가 변경사항이 일어날 때 이를 DB에 반여해줌
+
+Theme 객체는 영속성 상태이기 때문에 Hibernate는 조회 시점의 스냅샷과 flush 시점의 값을 비교한다.
+name 값이 달라졌기 때문에 dirty checking에 의해서 UPDATE SQL문이 실행된다.
+
+단, name을 바꿨는데, description, thumbnail_image_url까지 UPDATE 문에 포함되었다.
+이는 Hibernate가 기본적으로 변경된 컬럼만이 아니라 엔티티의 갱신 가능한 컬럼들을 함께
+UPDATE 문에 포함하기 때문이다. 변경 컬럼만 UPDATE하고 싶다면 별도 설정이 필요하다.

docs/jpa/LazyInitializationException.md

@@ -0,0 +1,71 @@
+## 관찰: LazyInitializationException
+
+### 시도한 코드
+
+Slot은 ReservationTime과 Theme을 `@ManyToOne(fetch = FetchType.LAZY)`로 가지고 있음.
+
+```java
+@ManyToOne(fetch = FetchType.LAZY)
+@JoinColumn(name = "time_id")
+private ReservationTime time;
+```
+
+Slot을 저장한 뒤 EntityManager로 Slot만 조회함.
+이때 ReservationTime은 아직 초기화하지 않음.
+
+그 뒤 테스트 트랜잭션을 종료하고, 트랜잭션 밖에서 `found.getTime().getStartAt()`을 호출함.
+
+```java
+Slot found = entityManager.find(Slot.class, slot.getId());
+
+TestTransaction.end();
+
+found.getTime().getStartAt();
+```
+
+### 예측한 SQL/동작
+
+Slot을 조회할 때는 Slot 테이블만 조회될 것이다.
+왜냐하면 Slot의 time 필드는 LAZY이기 때문이다.
+
+따라서 ReservationTime은 실제 객체가 아니라 프록시 상태로 남아 있을 것이라 예상함.
+
+그리고 트랜잭션이 끝난 뒤에는 영속성 컨텍스트가 닫히기 때문에,
+그 상태에서 프록시를 초기화하려고 하면 LazyInitializationException이 발생할 것이라 예상함.
+
+### 실제 SQL/동작
+
+Slot을 조회할 때 실행된 SQL
+
+```sql
+select s1_0.id,
+       s1_0.date,
+       s1_0.theme_id,
+       s1_0.time_id
+from slot s1_0
+where s1_0.id = ?
+```
+
+ReservationTime 테이블은 join되지 않았다.
+`Hibernate.isInitialized(found.getTime())` 값도 false였다.
+
+그 뒤 트랜잭션을 종료하고 `found.getTime().getStartAt()`을 호출하자
+`LazyInitializationException`이 발생했다.
+
+### 왜 그런가
+
+LAZY는 연관 객체를 지금 바로 가져오지 않고, 실제로 사용할 때 가져오겠다는 의미이다.
+
+Slot을 조회할 때 ReservationTime까지 같이 조회하지 않았기 때문에,
+Slot의 time 필드에는 진짜 ReservationTime 객체가 아니라 나중에 조회할 수 있는 프록시가 들어있다.
+
+트랜잭션 안에서는 이 프록시를 건드리는 순간 Hibernate가 DB에 추가 SELECT를 보내서 실제 ReservationTime을 가져올 수 있다.
+왜냐하면 아직 영속성 컨텍스트가 살아있고, DB 조회를 할 수 있는 Session이 연결되어 있기 때문이다.
+
+하지만 트랜잭션이 끝나면 영속성 컨텍스트도 닫힌다.
+이후에는 프록시가 실제 데이터를 가져오려고 해도 사용할 수 있는 Session이 없다.
+
+그래서 트랜잭션 밖에서 아직 초기화되지 않은 LAZY 필드에 접근하면 LazyInitializationException이 발생한다.
+
+정리하면 LazyInitializationException은 LAZY 자체가 문제라기보다,
+프록시를 초기화해야 하는 순간에 영속성 컨텍스트가 이미 닫혀 있어서 발생하는 예외이다.

docs/jpa/fetch기본값.md

@@ -0,0 +1,80 @@
+## 관찰: fetch 기본값
+
+### 시도한 코드
+
+테스트용 Entity를 따로 만들어서 fetch 옵션을 명시하지 않음.
+
+FetchDefaultReservation은 FetchDefaultTheme을 `@ManyToOne`으로 참조하게 만들고,
+FetchDefaultTheme은 FetchDefaultReservation 목록을 `@OneToMany`로 가지게 만듦.
+
+```java
+@ManyToOne
+private FetchDefaultTheme theme;
+```
+
+```java
+@OneToMany(mappedBy = "theme")
+private List<FetchDefaultReservation> reservations = new ArrayList<>();
+```
+
+그 뒤 각각을 조회하면서 연관 객체가 바로 초기화되는지 확인함.
+
+### 예측한 SQL/동작
+
+`@ManyToOne`은 fetch 옵션을 생략하면 기본값이 EAGER일 것이다.
+그래서 FetchDefaultReservation을 조회할 때 FetchDefaultTheme도 같이 조회될 것이라 예상함.
+
+반대로 `@OneToMany`는 fetch 옵션을 생략하면 기본값이 LAZY일 것이다.
+그래서 FetchDefaultTheme을 조회할 때 reservations 목록은 바로 조회되지 않고,
+실제로 목록에 접근하는 순간 SELECT SQL이 나갈 것이라 예상함.
+
+### 실제 SQL/동작
+
+`@ManyToOne`을 생략했을 때
+
+```sql
+select fdr1_0.id,
+       fdr1_0.name,
+       t1_0.id,
+       t1_0.name
+from fetch_default_reservation fdr1_0
+left join fetch_default_theme t1_0
+       on t1_0.id = fdr1_0.theme_id
+where fdr1_0.id = ?
+```
+
+FetchDefaultReservation을 조회하는 순간 FetchDefaultTheme도 함께 조회되었다.
+`Hibernate.isInitialized(found.getTheme())` 값도 true였다.
+
+`@OneToMany`를 생략했을 때
+
+Theme을 조회한 직후에는 reservations 목록이 초기화되지 않았다.
+`Hibernate.isInitialized(found.getReservations())` 값이 false였다.
+
+그 뒤 `found.getReservations().size()`처럼 목록에 접근하자 다음 SQL이 나갔다.
+
+```sql
+select r1_0.theme_id,
+       r1_0.id,
+       r1_0.name
+from fetch_default_reservation r1_0
+where r1_0.theme_id = ?
+```
+
+### 왜 그런가
+
+JPA에서 `@ManyToOne`의 기본 fetch 전략은 EAGER이다.
+그래서 다대일 관계에서는 연관된 단일 객체를 기본적으로 함께 가져오려고 한다.
+
+이번 테스트에서는 FetchDefaultReservation을 조회할 때 FetchDefaultTheme까지 left join으로 함께 조회되었다.
+즉, Reservation 입장에서는 Theme이 이미 초기화된 상태였다.
+
+반대로 `@OneToMany`의 기본 fetch 전략은 LAZY이다.
+일대다 관계에서는 연관된 컬렉션의 크기가 커질 수 있기 때문이다.
+Theme 하나를 조회했는데 그 Theme에 연결된 Reservation 목록까지 항상 가져오면 필요 없는 조회가 쉽게 많아질 수 있다.
+
+그래서 FetchDefaultTheme을 조회한 직후에는 reservations 목록이 프록시처럼 남아 있었고,
+실제로 목록의 size를 확인하는 순간에야 Reservation 목록을 조회하는 SELECT SQL이 실행되었다.
+
+정리하면 `@ManyToOne`은 기본값이 EAGER이고, `@OneToMany`는 기본값이 LAZY이다.
+하지만 실무 코드에서는 기본값에 기대기보다 fetch 전략을 명시해서 의도를 드러내는 것이 더 안전하다고 느껴진다.

docs/jpa/flush시점.md

@@ -0,0 +1,94 @@
+## 관찰: flush 시점
+
+### 시도한 코드
+
+Theme 객체를 DB에 저장한 뒤 다시 조회해서 영속성 컨텍스트에 올려놓음.
+그 뒤 Theme의 name 값을 바꾸고, 어떤 시점에 UPDATE SQL이 나가는지 확인함.
+
+이번에는 세 가지 경우를 나눠서 봄.
+
+```
+1. entityManager.flush()를 직접 호출함
+2. Theme을 변경한 뒤 JPQL을 실행함
+3. Theme을 변경한 뒤 트랜잭션을 종료함
+```
+
+### 예측한 SQL/동작
+
+Theme의 name 값을 바꾸는 순간 바로 UPDATE가 나가지는 않을 것이다.
+왜냐하면 객체의 값이 바뀐 것이지, 아직 DB와 동기화된 것은 아니기 때문이다.
+
+대신 flush가 발생하는 시점에 Hibernate가 변경 감지를 하고 UPDATE SQL을 날릴 것이다.
+
+```sql
+update theme
+set description=?,
+    name=?,
+    thumbnail_image_url=?
+where id = ?
+```
+
+JPQL을 실행하는 경우에는 JPQL SELECT를 하기 전에 먼저 UPDATE가 나갈 것이라 예상함.
+왜냐하면 JPQL은 DB를 직접 조회하기 때문에, 조회 전에 영속성 컨텍스트의 변경사항을 DB에 맞춰야 하기 때문이다.
+
+### 실제 SQL/동작
+
+명시적으로 flush()를 호출했을 때
+
+```sql
+update theme
+set description=?,
+    name=?,
+    thumbnail_image_url=?
+where id = ?
+```
+
+JPQL을 실행했을 때
+
+```sql
+update theme
+set description=?,
+    name=?,
+    thumbnail_image_url=?
+where id = ?
+```
+
+```sql
+select t1_0.id,
+       t1_0.description,
+       t1_0.name,
+       t1_0.thumbnail_image_url
+from theme t1_0
+where t1_0.id = ?
+```
+
+트랜잭션을 종료했을 때
+
+```sql
+update theme
+set description=?,
+    name=?,
+    thumbnail_image_url=?
+where id = ?
+```
+
+### 왜 그런가
+
+flush는 영속성 컨텍스트의 변경사항을 DB에 반영하는 동기화 시점이다.
+
+Theme 객체의 name을 바꿨을 때 그 순간 바로 UPDATE SQL이 나가지는 않았다.
+이때는 아직 영속성 컨텍스트 안의 객체 상태만 바뀐 상태이다.
+
+그 뒤 entityManager.flush()를 직접 호출하니 Hibernate가 영속성 컨텍스트 안의 스냅샷과 현재 값을 비교했고,
+name 값이 달라진 것을 확인해서 UPDATE SQL을 실행했다.
+
+JPQL을 실행할 때도 UPDATE가 먼저 나갔다.
+처음에는 SELECT만 나갈 수도 있다고 생각할 수 있지만, JPQL은 DB에서 데이터를 조회한다.
+만약 변경사항을 DB에 반영하지 않고 SELECT를 먼저 실행하면, DB는 아직 예전 값을 가지고 있을 수 있다.
+그래서 Hibernate는 JPQL 실행 직전에 flush를 먼저 해서 영속성 컨텍스트와 DB를 맞춘다.
+
+트랜잭션이 끝날 때도 flush가 발생했다.
+커밋 전에 영속성 컨텍스트의 변경사항을 DB에 반영해야 최종적으로 변경 내용이 저장될 수 있기 때문이다.
+
+정리하면 flush는 commit 자체는 아니지만, commit 전에 필요한 DB 동기화 과정이다.
+그리고 flush는 직접 호출할 때뿐만 아니라 JPQL 실행 직전, 트랜잭션 커밋 시점에도 발생할 수 있다.