728x90 Spring Boot38 📌 Spring Transaction에서 ReadOnly가 정상 동작하지 않았던 이유와 해결 과정 1. 배경우리 서비스는 RW(Read-Write) / RO(Read-Only) DB를 분리 운영하고 있으며,Spring의 AbstractRoutingDataSource를 상속한 Custom RoutingDataSource를 통해트랜잭션 readOnly 여부에 따라 사용하는 DB를 분기하도록 구성되어 있다.구조는 아래와 같다.AbstractRoutingDataSource 내부의 targetDataSources(Map)RW → Master DBRO → Slave DBdetermineCurrentLookupKey() 오버라이드TransactionSynchronizationManager.isCurrentTransactionReadOnly() 값에 따라"RW" 또는 "RO" key 반환즉, @Transaction.. 2025. 12. 3. JUnit5 시작 * 의존성 추가(2.1 이하 버전의 경우) org.junit.jupiter junit-jupiter 5.5.1 test @BeforeAll > 모든 단위 테스트 실행 전 단 한번만 실행(단 한 번만 호출됨) / 반드시 static void @AfterAll > 모든 단위 테스트 실행 후 단 한번만 실행(단 한 번만 호출됨) / 반드시 static void @BeforeEach > 각 단위 테스트 실행 이전 실행 @AfterEach > 각 단위 테스트 실행 이후 실행 @DisplayNameGeneration > 메서드, 클래스를 참조하여 테스트 이름을 정할 수 있음 @DisplayName > @DisplayNameGeneration보다 우선순위가 높고, 테스트의 이름을 표현할 수 있음(권장) 2023. 8. 14. @Transactional Isolation(격리 수준) 종류 READ_UNCOMMITED (level 0) READ_COMMITED (level 1) REPEATABLE_READ (level 2) SERIALIZABLE (level 3) READ_UNCOMMITED : 트랜잭션 처리중인(Uncommitted or Dirty) 데이터를 읽을 수 있다. READ_COMMITED : 커밋된 데이터만 읽을 수 있음 (dirty read 방지) REPEATABLE_READ : 트랜잭션이 완료될 때까지 SELECT문에 사용되는 모든 데이터에 shared lock이 걸려 데이터 수정이 불가능하다. * phantom read (한 트랜잭션 내에서 같은 쿼리를 두 번 수행 시, 첫 번째 쿼리에서 없던 레코드가 두 번째 쿼리에서 발생하거나 없어질.. 2023. 2. 5. The called method's class hierarchy was loaded from the following locations 2022-03-26 18:11:26.326 INFO 17027 --- [ main] c.e.redissample.RedissampleApplication : Starting RedissampleApplication using Java 1.8.0_282 on cheolju.ECM with PID 17027 (/Users/cheolju/IdeaProjects/springbootredis/redissample/target/classes started by cheolju in /Users/cheolju/IdeaProjects/springbootredis/redissample) 2022-03-26 18:11:26.328 INFO 17027 --- [ main] c.e.redissample.RedissampleAp.. 2022. 3. 26. 이전 1 2 3 4 ··· 10 다음 728x90