1. QueryDSL 을 이용한 동적 쿼리 생성
pageable 객체만 넘겨주면 되는 JPQL 방식과 다르게 Querydsl 방식은 쿼리에 offset, limit 를 추가해야하고 총 데이터의 개수도 별도의 쿼리를 통해 값을 구해야해서 단순한 쿼리는 JPQL 방식을 사용하는 것이 더 나은 것 같다고 느꼇다.
하지만 복잡한 쿼리의 경우 각각의 조건들을 작성할때 컴파일 에러를 통해 바로 문제점을 확인할 수 있으며 리팩토링과 유지보수 부분에서도 문자열로 작성되는 JPQL 보다 훨씬 장점이 있다고 느꼈다.
코드 작성 과정에서 한 가지 실수가 있기도 하였는데 todo 테이블과 manager, comment 테이블을 조인하는 경우 todo 의 수를 집계하는 과정에서 중복된 todo가 집계될 수 있으므로
todo.id.countDistinct()
를 통해 중복 집계를 막는 것도 빼놓지말고 고려해야될 것 같다.
2. @Transactional 전파
생성된 todo 에 해당 todo를 관리할 매니저를 등록하는 과정에서 항상 로그를 남기게 설정하고자 하였다. 이 과정에서 로그의 기록은 todo에 매니저를 등록하는 트랜잭션이 실패하든 실패하지 않든 항상 커밋이 되도록 설정하고자 하였고, 이러한 이유로 트랜잭션 전파 옵션중에서 기존에 진행중이던 트랜잭션이 있으면 해당 트랜잭션을 잠시 중단하고 새로운 트랜잭션을 생성하여 독립적으로 롤백과 커밋을 하는 REQUIRES_NEW 옵션을 사용하였다.
| 항목 | REQUIRED | REQUIRES_NEW | |
| 새로운 트랜잭션 생성 | 필요할 때만 | 항상 | |
| rollback 영향 | 전체 롤백 | 독립 롤백 | |
| commit 영향 | 같이 commit | 독립 commit |
@Transactional 의 기본값인 REQUIRED와 비교해보면 위 표와 같은 차이점을 가지고 있다.
'트러블슈팅' 카테고리의 다른 글
| 최적화 전략 설계 방법 (0) | 2026.03.26 |
|---|---|
| TTL , Evict 설계 기준 (0) | 2026.03.26 |
| 클라우드 아키텍쳐 설계 & 배포 (0) | 2026.02.03 |
| Spring 코드 개선 (0) | 2026.01.27 |
| 권한 처리 전략 (0) | 2026.01.21 |