Transactional 어노테이션 관련

안녕하세요! @Transactional 어노테이션을 어떻게 적용하셨는지, 그리고 에러가 어떻게 발생을 하는건지를 명확하게 알수는 없어 정확한 답변을 드리긴 어려울것 같고 힌트가 될수 있는 내용을 말씀드려보겠습니다. 아마도 Isolation Level 이 힌트가 되지 않을까 싶은데요, Isolation Level 은 동시에 서로 다른 트랜잭션이 수행될 때 다른 트랜잭션이 동일한 데이터에 대해서 어떻게 보일지에 대한 범위를 나타냅니다. 만약 회원 테이블에 데이터를 주입하는 로직과 학생 테이블에 데이터를 주입하는 로직의 트랜잭션이 나뉘어져 있고 이때 isolation level 을 기본값으로 잡았다면 commit 되지 않은 데이터를 읽어들일 수 없게 되어 말씀하신 에러가 발생할 수 있습니다.(DBMS 에 따라 다르지만 대부분의 isolation level default 값이 commit 되지 않은 데이터는 가지고 오지 못하는 형태로 정의됩니다.) 만약 이게 맞다면 isolation level 을 commit 되지 않은 데이터도 읽을 수 있는 가장 느슨한 형태인 READ_UNCOMMITTED 로 설정하면 해결하실 수 있습니다. 위 내용에 대한 연장선으로 회원 테이블에 데이터를 주입하는 로직과 학생 테이블에 데이터를 주입하는 로직의 Transaction 이 나뉘어진게 맞다면, Transaction 이 나뉘지 않고 동일한 Transaction 으로 묶여지도록 지정해 주는것도 방법일것 같습니다. 이 부분은 Transaction Propagation 이란 키워드로 검색을 해보시면 힌트를 얻으실 수 있을것 같습니다. 마지막으로 회원 테이블 등록에 대한 commit 이 완료된 뒤 학생 테이블 등록을 진행하는 즉, Transaction 을 각 로직별로 명확하게 분리하고 순차적으로 진행시키도록 로직을 구성하는 방법이 있습니다. 기능에 대한 정확한 스펙을 몰라 이렇게 해도 될지는 스스로 판단을 하셔야할듯 합니다만, 회원 테이블과 학생 테이블 등록에 대한 rollback 이 반드시 같이 발생하지 않아도 된다면 (회원 테이블엔 데이터가 있지만 학생 테이블엔 데이터가 없는 상황이 발생해도 괜찮다면) 이것도 방법이 되지 않을까 싶네요. 앞서 설명드린 Isolation Level 과 Propagation 에 대해 이전에 정리한 글이 있어 공유드립니다. - https://careerly.co.kr/comments/87869?utm_campaign=self-share 부디 저의 짧은 지식이 도움이 되시길 바라겠습니다.