연결 풀에서 이전 요청의 시간대나 임시 설정이 다음 요청에 남습니다. 연결 반환 때 무엇을 초기화해야 하나요?

풀은 물리 연결을 재사용하므로 세션 변수·트랜잭션·임시 객체·역할 같은 상태가 다음 요청에 남을 수 있습니다. 요청이 끝났다는 애플리케이션 상태와 DB 세션이 깨끗하다는 사실을 구분해야 합니다.

동작 원리와 전제

요청 A가 세션 시간대나 검색 경로를 바꾸고 그대로 반납하면 B의 쿼리가 다른 의미로 실행될 수 있습니다. 가능하면 transaction-local 설정을 사용하고, 반환 시 rollback·reset 절차와 드라이버 계약을 확인합니다. 사용자 역할을 세션에 저장하는 구성은 특히 인가 누출을 주의합니다.

선택과 실패 처리

취소된 쿼리의 결과를 아직 읽고 있는 연결은 즉시 재사용하면 프로토콜 응답이 섞일 수 있습니다. 드라이버가 정리 완료를 보장하는지 확인하고 불확실한 연결은 폐기합니다. 모든 reset이 무료는 아니므로 필요한 상태를 최소화하고 세션 의존 로직을 줄입니다.

구체적인 사례와 검증

요청 A가 검색 경로를 tenant A 스키마로 바꾼 연결을 반환하고 B가 같은 연결을 받으면, SQL이 같아도 다른 데이터에 접근할 수 있습니다. 설정을 코드에서 다시 넣는 방식만으로는 예외 경로의 누락을 막기 어려워 transaction-local scope나 검증된 pool reset을 사용합니다. reset이 실패하면 그 연결을 정상 풀에 돌려보내지 않습니다. prepared statement나 임시 테이블도 연결별 상태라서 세션 재설정과 성능 영향이 있을 수 있습니다. 풀의 일반적인 테스트뿐 아니라 물리 연결 하나만 사용하게 강제한 테스트로 이전 요청 상태가 다음 요청에 남는지 확인하겠습니다.

같은 연결을 강제로 재사용하는 테스트에서 시간대·role·transaction·예외·취소 경로를 확인합니다. 풀 크기를 늘려 증상을 가리기보다 획득·반환의 상태 계약을 고칩니다. 요청별 문맥은 연결의 우연한 이전 사용자가 아니라 명시적인 입력으로 관리합니다.