Conversation
WalkthroughMemberRepository에 userId 기반 삭제 및 존재 확인 메서드가 추가되었다. UserService의 deleteAccount는 트랜잭션으로 감싸지고, 사용자 삭제 전 관련 Member 레코드를 삭제하며, 액세스 토큰 무효화는 커밋 이후 콜백으로 지연 실행되도록 변경되었다. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor U as User
participant US as UserService
participant MR as MemberRepository
participant UR as UserRepository
participant TS as Tx Manager
rect rgba(200,230,255,0.3)
note over US: deleteAccount(userId) 시작 (@Transactional)
U->>US: 요청: 계정 삭제
US->>MR: existsByUserId(userId)?
alt Member 존재
US->>MR: deleteByUserId(userId)
end
US->>UR: deleteById(userId)
US->>TS: afterCommit 콜백 등록(토큰 무효화)
note over US: 트랜잭션 커밋
end
rect rgba(220,255,220,0.3)
note over TS: afterCommit
TS-->>US: 콜백 호출
US->>US: 액세스 토큰 무효화
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/main/java/com/WhoIsRoom/WhoIs_Server/domain/user/service/UserService.java (1)
188-190: 선택적 최적화: existsByUserId 체크를 생략할 수 있습니다.
deleteByUserId는 레코드가 없어도 안전하게 실행되므로,existsByUserId체크 없이 바로 호출해도 됩니다. 다만 가독성이나 명시적인 의도 표현을 위해 현재처럼 유지하는 것도 괜찮습니다.원한다면 다음과 같이 간소화할 수 있습니다:
- if (memberRepository.existsByUserId(userId)) { - memberRepository.deleteByUserId(userId); - } + memberRepository.deleteByUserId(userId);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/com/WhoIsRoom/WhoIs_Server/domain/member/repository/MemberRepository.java(1 hunks)src/main/java/com/WhoIsRoom/WhoIs_Server/domain/user/service/UserService.java(2 hunks)
🔇 Additional comments (6)
src/main/java/com/WhoIsRoom/WhoIs_Server/domain/member/repository/MemberRepository.java (2)
29-31: LGTM! 사용자 ID 기반 Member 삭제 메서드가 올바르게 구현되었습니다.@Modifying 어노테이션과 JPQL 쿼리가 적절하게 사용되었고, clearAutomatically와 flushAutomatically 플래그도 제대로 설정되어 있네요. UserService의 회원 탈퇴 로직에서 외래 키 제약 조건 문제를 해결하는 데 필요한 메서드입니다.
33-33: LGTM! 존재 여부 확인 메서드가 올바르게 선언되었습니다.Spring Data JPA의 네이밍 컨벤션을 따르고 있어서 구현체가 자동으로 생성됩니다. UserService에서 불필요한 삭제 쿼리 실행을 방지하는 데 활용되고 있습니다.
src/main/java/com/WhoIsRoom/WhoIs_Server/domain/user/service/UserService.java (4)
28-29: LGTM! 트랜잭션 동기화에 필요한 임포트가 추가되었습니다.afterCommit 콜백 구현을 위해 필요한 클래스들이 올바르게 임포트되었습니다.
183-183: 굿! @transactional 어노테이션이 추가되어 트랜잭션 무결성이 보장됩니다.회원 탈퇴 로직이 이제 트랜잭션으로 관리되어, Member 삭제와 User 삭제가 원자적으로 처리됩니다. 만약 중간에 오류가 발생하면 전체가 롤백되므로 데이터 일관성이 유지됩니다.
196-201: 좋은 개선입니다! 토큰 무효화를 트랜잭션 커밋 이후로 지연시켰습니다.
TransactionSynchronization의afterCommit콜백을 사용하여, 데이터베이스 작업이 성공적으로 커밋된 후에만 액세스 토큰이 무효화되도록 보장합니다. 이렇게 하면 트랜잭션이 롤백될 경우 토큰이 무효화되지 않아 일관성이 유지됩니다.
203-203: SecurityContextHolder 클리어 타이밍 확인이 필요합니다.Line 203의
SecurityContextHolder.clearContext()가 트랜잭션 커밋 전에 즉시 실행됩니다. 만약 이후에 트랜잭션이 롤백되면 사용자는 여전히 존재하지만 보안 컨텍스트는 이미 클리어된 상태가 됩니다.토큰 무효화처럼
afterCommit콜백 안에서 실행하는 것이 더 안전할 수 있습니다. 현재 동작이 의도된 것인지 확인해 주세요.필요하다면 다음과 같이 수정할 수 있습니다:
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { @Override public void afterCommit() { jwtService.invalidAccessToken(accessToken); + SecurityContextHolder.clearContext(); } }); - - SecurityContextHolder.clearContext();
Related issue 🛠
Work Description 📝
Screenshot 📸
Uncompleted Tasks 😅
To Reviewers 📢
Summary by CodeRabbit