[feat/fix] 그룹 생성 API, 우분투 그룹 관련 버그 수정

[saokiritoni]

🌱 관련 이슈

• close : [ bug ] 그룹 생성 시 ObjectOptimisticLockingFailureException #100

🌱 작업 사항

• 그룹 생성 API : POST /api/groups
• 우분투 그룹 관련 버그 수정

🌱 참고 사항

우분투 그룹 관련 버그 수정

• Group 자체에 그룹 PK용 ID를 추가하고, 기존의 mapsId를 제거함.
• usedId는 매핑용으로만 사용

1. 첫 번째 문제: ObjectOptimisticLockingFailureException
@MapsId와 @OneToOne 매핑이 Group과 UsedId 엔티티의 ID를 동일하게 사용하면서, JPA의 영속성 컨텍스트에서 충돌이 발생 -> groupService에서 UsedId 엔티티를 저장할 때 save() 대신 saveAndFlush()를 사용해 데이터베이스에 즉시 반영하도록 수정, Group 엔티티를 저장하기 전에 UsedId의 존재를 확실히 보장하여 충돌을 피할 것이라고 예상했으나 실패함.!!!! @MapsId를 유지하는 방향으로 하고싶었는데, 아무리 해도 락 문제때문에 실패함...엔티티가 그대로 있을 땐 아무 문제 없는데, 그룹을 생성하려고 하면 락 문제가 바로 생김.

여기서 생성 시점/순서의 문제?

• Group과 UsedId가 동일한 ID(같은 행) 공유하는 상태. 그리고 이 엔티티를 하나의 트랜잭션 내에서 순서대로 저장하는 흐름을 만들고 있었음.
• usedIdRepository.save(newUsedId)를 호출: JPA가 newUsedId를 영속성 컨텍스트에 추가하고, 트랜잭션 커밋 시점에 insert날릴 준비하고 saveAndFlush()로 바로 실행
• groupRepository.save(group)를 호출: JPA가 group을 영속화하려고 시도, 이때 @MapsId 때문에, Group 의 PK를 usedId의 ID로 설정해야 함. -> 여기에서 JPA는 usedId가 이미 영속성 컨텍스트를 존재한다고 알고있고, JPA가 group을 저장하면서 usedId가 변경되었을 가능성을 체크함. 이 과정이 트랜잭션의 잠금 상태 / 버전관리 로직과 얽히면서 동일한 ID에 대해 동시성 충돌이 발생

2. 두 번째 문제: null identifier
@MapsId를 제거하고 @GeneratedValue를 Group 엔티티에 추가했지만, ubuntuGid가 여전히 UsedId의 외래 키 역할을 하면서 JPA가 인식을 제대로 못함. -> @MapsId 매핑을 포기하고, Group 엔티티가 groupId라는 자체적인 PK를 갖도록 엔티티를 재구성.

엔티티 결론

• Group : UsedId = 1:1

• UsedId는 우분투 서버의 UID, GID를 관리

• Group은 ubuntuGid를 사용해 UsedId 엔티티를 참조

• ID를 공유하는 @MapsId 제거하고 엔티티 역할 분리

• Request : UsedId = N:1 (수정사항 없음)