회원 정보 수정 API를 구현하며 dirty checking을 이용한 회원 정보 update를 사용했습니다.service의 update 메소드를 호출하기 전과 후를 controller단에서 로그를 찍어보니 정보가 잘 변경되는데 DB에는 반영이 되지 않아 애를 먹었습니다.serviceImpl단의 update 메소드에 @Transactional을 붙여서 해결했습니다. 그 전에는 service단의 update 메소드에 @Transactional을 붙였더니 안되더라구요.service단의 메소드에 붙이는 @Transactional와 serviceImpl단의 메소드에 붙이는 @Transactional이 다른 트랜잭션으로 작동하는건지, 그렇다면 어디에 @Transactional을 붙이는게 맞는건지 궁금합니다.

@Service @RequiredArgsConstructor public class SignUpMemberService implements SignUpMemberUseCase { private final MemberRepository memberRepository; @Override public Long invoke(final Command command) { validateEmailIsUnique(command.email()); validateNicknameIsUnique(command.nickname()); validatePhoneIsUnique(command.phone()); final Member member = command.toDomain(); return memberRepository.save(member).getId(); } } @Service @Transactional @RequiredArgsConstructor public class SignUpMemberService implements SignUpMemberUseCase { private final MemberRepository memberRepository; @Override public Long invoke(final Command command) { validateEmailIsUnique(command.email()); validateNicknameIsUnique(command.nickname()); validatePhoneIsUnique(command.phone()); final Member member = command.toDomain(); return memberRepository.save(member).getId(); } }사용자 가입 UseCase에 대한 구현에서 앞단에서는 unique field에 대한 validation을 진행합니다그 후에 memberRepository.save(member)를 진행하는데 (memberRepository는 Data Jpa Repo)아시다시피 SimpleJpaRepository의 save흐름에는 @Transactional이 적용되어 있습니다따라서 이 SignUpMemberService의 invoke 흐름부터 굳이 @Transactional을 걸어야 하는 생각이 듭니다물론 붙임으로써 이 메소드가 writable한 로직을 가진다고 코드레벨에서 알고 JPA를 모르는사람은 SimpleJpaRepository의 구조를 모르기 때문에 가독성?적인 측면에서는 붙이는게 이해에 수월하다고 생각하는데 tx scope를 최대한 짧게 가져가는게 좋다는 생각이 들어서 약간의 고민을 하게 되었습니다 

안녕하세요 재고관리시스템 강의를 복습하며 내용을 정리하는 중 의문이 생겨 질문을 드립니다.  가장 처음에 application code 레벨에서만 동시성을 해결하기 위해 syncrhonized 를 사용할 경우 해당 메서드에는 @Transactional 을 붙여서는 안된다고 설명해 주셨습니다. 실제로 이를 붙일 경우, 동시에 decrease 메서드가 호출되고 해당 로직 내부로 들어가는 것이 가능함을 확인하였습니다.  그런데 여기서 제가 의문이 들었던 것이 있습니다. @Transacitonal 을 사용할 경우 Spring AOP 에 의해 매 번 다른 proxy 인스턴스를 통해 target object 로의 호출을 하게 됩니다. proxy 객체에 대한 lock 은 서로 다른 프록시들 사이에 공유되지 않는다고 하더라도, 내부적으로 호출되는 target 객체에 대한 decrease 메서드는 결국 동일한 객체에 대한 호출을 하기 때문에, 공유되는 lock 에 대한 경쟁이 일어나는 것이 아닌가 생각이 들었습니다. 최종적으로는 target 객체에 대한 synchronized 메서드를 호출하는 것이라면, 단 하나의 스레드만 임계 영역에 들어갈 수 있어야 할 것 같은데, 그렇지 않음을 확인하였습니다.   왜 이런 일이 일어나는 것인지 이해가 잘 되지 않습니다 ㅠㅠ 이와 관련해서 어떤 키워드로 공부해보면 좋을지 추천 가능할까요..?