중간테이블에 대한 낙관적 락 적용법

현재 Member 테이블과 Appointment 테이블이 존재하는데, N:N 관계이기 때문에 아래와 같이 AppointmentUser라는 중간 테이블이 존재합니다.

@Entity
@Table(name = "appointment_and_user")
public class AppointmentUser extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "apppointment_id", nullable = false)
    private Appointment appointment;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id", nullable = false)
    private Member member;

    @Enumerated(value = EnumType.STRING)
    @Column(name = "member_authority", nullable = false)
    private MemberAuthority memberAuthority;

    @Version
    private Long version;

하나의 AppointmentUser 테이블은 약속과 멤버의 id를 하나씩 가집니다.

여기서 레포지토리의 코드는 이러합니다.

public interface AppointmentUserRepository extends JpaRepository<AppointmentUser, Long> {

...

    @Lock(LockModeType.OPTIMISTIC)
    @Query("select au from AppointmentUser au where au.id = :id")
    AppointmentUser findByIdWithOptimisticLock(Long id);

findByIdWithOptimistic 메서드를 통하여 특정 유저-약속 테이블의 데이터를 통해 AppointmentUser 객체를 반환합니다.

서비스 계층의 코드는 아래와 같습니다.

@Transactional
public void updateAuthority(Long appointmentId, Long loginMemberId, Long targetMemberId) {
    Member loginMember = memberRepository.getById(loginMemberId);
    Member targetMember = memberRepository.getById(targetMemberId);
    Appointment appointment = appointmentRepository.getById(appointmentId);
    AppointmentUser loginAppointmentUser = appointmentUserRepository.getByMemberAndAppointment(loginMember, appointment);
    AppointmentUser targetAppointmentUser = appointmentUserRepository.getByMemberAndAppointment(targetMember, appointment);
    appointment.changeTitle("asd");

    validateIsAdminMember(loginAppointmentUser.getId());
    MemberAuthority targetAuthority = targetAppointmentUser.getMemberAuthority();

    targetAppointmentUser.updateAuthority(MemberAuthority.getAnotherAuthority(targetAuthority));
    appointmentRepository.save(appointment);
    appointmentUserRepository.save(targetAppointmentUser);
}

private void validateIsAdminMember(Long loginAppointmentUserId) {
    if (appointmentRepository.findByIdWithOptimisticLock(loginAppointmentUserId).getMemberAuthority() != MemberAuthority.ADMIN) {
        throw new NotAdminMemberException();
    }
}

<로직 설명>

• 하나의 약속 내에 멤버 두명이 존재

• 각 멤버들은 ADMIN or NORMAL 권한을 갖고 있음.

• 두명 다 약속 내 에서 ADMIN 권한을 갖고 있다는 상황을 가정. (ADMIN은 AppointmentUser 엔티티의 MemberAuthority 라는 필드의 Enum 값입니다.)

• 두명이 서로를 동시에 ADMIN에서 NORMAL로 권한을 박탈하는 경우, 하나의 약속 안에 ADMIN인 사람이 없어지는 예외적인 문제 상황이 발생함.

• 그래서 @Version을 AppointmentUser 엔티티의 필드로 등록하여 해결하려고 했으나..

• 사용자 A와 B가 있다고 할 때 service 코드 내의 validateIsAdminMember 메서드를 통해 상대방의 권한을 박탈하려는 유저(본인)가 ADMIN인지 검증하여 ADMIN이 맞다면 박탈하고, ADMIN이 아니라면, 예외를 던지게 끔 하는 로직에서,

• 레포지토리 내의 findByIdWithOptimisticLock 메서드를 동시에 접근했을때 Version 필드를 통해 동시성 문제를 제어할 수 있다고 생각했으나..

• validateIsAdminMember로 검증하는 A와 B의 AppointmentUser 엔티티는 서로 다른 객체(데이터)이기 때문에 서로 다른 테이블의 Version 값을 변경하기 때문에 동시성 보장이 안됨..

• 그래서 Appointment에 Version필드를 넣어주려 했지만, Version값은 해당 테이블에 변화가 생겨야 변한다.

• 하지만 로직상, AppointmentUser(중간테이블)에 변화가 생기는게 맞다...

위와 같은 중간 테이블 사용으로 인한 문제가 발생하였을 때 어떻게 강의자님이시라면 어떻게 해결하실지 궁금합니다!