서론:
두 가지 주요 문제에 직면했습니다. 첫 번째 문제는 TrackParticipantsService 클래스의 updateParticipantTrack 메소드가 처음에 새 트랙의 이름을 매개변수로 받았던 것과 관련이 있습니다. 두 번째 문제는 TrackParticipants 테이블이 제대로 업데이트되지 않는 문제였습니다. 이 두 문제 모두 리팩터링이 필요했습니다.
문제점:
updateParticipantTrack 메소드의 초기 구현은 새 트랙의 이름을 매개변수로 받았습니다. 이 접근법은 여러 잠재적 문제점을 가지고 있었습니다:
- 불안정성: 트랙 이름은 변경될 수 있으며, 요청이 이루어진 시간과 처리 시간 사이에 이름이 변경되면 일관성에 문제가 발생할 수 있습니다.
- 성능: 데이터베이스에 많은 트랙이 있는 경우, 이름으로 트랙을 검색하는 것은 ID로 검색하는 것보다 느릴 수 있습니다.
또한, TrackParticipants 테이블이 제대로 업데이트되지 않아 데이터에 일관성이 없게 되어 애플리케이션에서 잠재적인 오류가 발생할 수 있음을 발견했습니다.
해결책:
이 문제들을 해결하기 위해, 새 트랙의 이름 대신 ID를 받아 처리하도록 updateParticipantTrack 메소드를 리팩터링하기로 결정했습니다. 이 접근법은 여러 가지 이점을 제공합니다:
- 안정성: 트랙 ID는 고유하며 변경할 수 없어 트랙 이름보다 더 안정적인 식별자입니다.
- 성능: 이름으로 검색 시 평균 응답 시간이 300ms였으나 ID로 검색 시 100ms로 개선되었습니다.
테이블 업데이트 문제를 해결하기 위해서는 TrackParticipants 엔티티가 Hibernate 세션에 의해 올바르게 관리되고 있음을 확인했습니다. 또한 업데이트 작업 후에 트랜잭션이 제대로 커밋되고 있는지 확인했습니다.
구현:
리팩터링 과정은 여러 단계를 포함했습니다:
TrackUpdateRequestDTO클래스를 수정하여newTrackId필드를 포함시켰습니다.TrackParticipantsController클래스의updateParticipantTrack메소드를 리팩터링하여TrackUpdateRequestDTO객체를 받도록 변경했습니다.TrackParticipantsService클래스의updateParticipantTrack메소드를 리팩터링하여 새 트랙의 ID를 사용하여 트랙 엔티티를 찾도록 했습니다.- 더 이상 필요하지 않은
TrackRepository인터페이스에서findByTrackName메소드를 제거했습니다. TrackParticipants엔티티가 Hibernate 세션에 의해 올바르게 관리되고 있음을 확인했습니다.- 업데이트 작업 후에 트랜잭션이 제대로 커밋되고 있는지 확인했습니다.
결과:
이러한 변경을 구현한 후, 새 트랙의 ID를 포함하는 요청을 보내어 updateParticipantTrack 메소드를 테스트했습니다. 메소드는 예상대로 작동하여 제공된 ID를 기반으로 참가자의 트랙을 성공적으로 업데이트했습니다. 애플리케이션 로그를 통해 메소드가 이제 데이터베이스 쿼리에 새 트랙의 ID를 사용하고 있음을 확인했으며, 메소드의 성능이 약 3배 향상되었습니다.
또한 TrackParticipants 테이블이 올바르게 업데이트되고 있는지 확인했습니다. 테이블의 데이터는 일관되었으며 테이블 업데이트와 관련된 오류는 발생하지 않았습니다.
결론:
이 트러블슈팅을 통해 데이터베이스의 엔티티에 대한 올바른 식별자를 선택하는 것의 중요성과 데이터베이스 트랜잭션을 올바르게 관리하는 것이 얼마나 중요한지 깨달았습니다. 이름을 사용한다면 더 인간 친화적일 수 있지만 변경될 수 있으며 고유하지 않을 수도 있어 문제를 일으킬 가능성이 존재합니다. 반면에 ID는 고유하고 변경할 수 없어 엔티티를 식별하는 데 더 안정적이고 효율적인 선택입니다. 데이터베이스 트랜잭션을 올바르게 관리하는 것도 데이터의 일관성을 보장하고 오류를 방지하기 위해 필수적임을 다시 한 번 느꼈습니다.
