연습 세션에 분석 시도 번호와 시작 시각을 추가할 때 두 가지를 확인하려고 했습니다. 기존 행을 조회하면 새 필드에 기본값이 들어가야 하고, 값을 채운 행을 조회하면 매퍼가 새 필드를 올바르게 읽어야 했습니다. 처음에는 테스트 행 하나로 두 가지를 검사했습니다. MyBatis로 먼저 읽고 JdbcTemplate로 값을 바꾼 뒤 같은 매퍼에서 다시 읽었습니다. 두 번째 조회에는 변경 전 시도 번호가 남아 있었습니다.

세션 캐시가 재조회를 가로막은 이유

테스트는 Spring 트랜잭션 안에서 실행됐고, MyBatis는 같은 SqlSession을 사용했습니다. MyBatis의 기본 로컬 캐시는 세션 안에서 같은 쿼리를 같은 인자로 요청하면 이전 결과를 재사용할 수 있습니다. 매퍼의 갱신은 이 캐시를 비우지만, 여기서 값을 바꾼 것은 JdbcTemplate였습니다. 같은 트랜잭션에서 SQL을 실행했어도 MyBatis가 자신의 캐시에 있는 조회 결과를 무효화할 계기는 없었습니다.

값이 바뀌었는지를 보려면 먼저 두 번째 읽기가 DB에 도달했는지 구분해야 합니다. 이 사례의 오래된 결과는 변경 SQL이 실패했다는 증거가 아니었습니다. 첫 조회의 결과를 재사용하는 경로가 테스트에 섞인 것이었습니다.

기본값과 새 필드 매핑을 별도 행으로 검증

기본값은 건드리지 않은 별도 세션에서 확인했습니다. 새 필드에 값을 채우는 세션은 JDBC 갱신이 끝난 뒤에 처음 읽었습니다. 이제 두 검사가 각각 필요한 상태에서 매퍼를 호출했고, 앞 검사에서 읽은 값에 기대지 않았습니다. 임시 MySQL 검사에서 손대지 않은 행의 시도 번호는 0이었고 시작 시각은 비어 있었습니다. 갱신한 행에서는 시도 번호 1과 저장한 마이크로초 단위 시각을 읽었습니다. 전역 localCacheScope 설정은 그대로 뒀습니다. 확인하려던 대상은 새 칸의 기본값과 매핑이었고, 세션 캐시 자체의 설정 변경은 필요하지 않았습니다. MyBatis 로컬 캐시 설정