JDBC 9

직전 포스팅에서 repository layer에 특정 DB에 종속적인 코드가 들어가 버렸다.

e.getErrorCode() == 23505

해당 코드는 H2 한정이다..

 

지금까지 특정 DB에 따른 코드 분리는 필요 없었지만..

DataSource가 라이브러리에 등록된 DB 드라이버, DB접근 URL 및 부가정보(이름, 비밀번호 등)로

알아서 커넥션 획득해줬기 때문..

 

예외처리 때문에 코드 분리를 하거나.. 코드가 지저분해질 위기에 처했다.

 

해결..

스프링은 이미 모든 DB에러 상황에 맞는 예외를 만들어 놨으며..

-> 스프링 데이터 접근 예외(DataAccessException) 계층

DB에 따른 error code들을 매핑하여, 동일한 원인일 경우 일관된 예외로 변환 가능하다.

-> 스프링 예외 변환기(SQLExceptionTranslator)

(DB에 따른 종속성을 피했지만.. 스프링 종속성은 생긴다..)

 

스프링 데이터 접근 예외 추상화

어떤 DB와 접근 기술(순수JDBC, JPA 등)에 에 종속적이지 않게 설계 되어있다.

따라서 서비스 계층에도 사용 가능하다.

-> 처리 가능한 예외 라면 서비스 계층에서 스프링이 제공하는 예외를 받아서 처리 하면 된다.

 

스프링에서 제공하는 데이터 접근 예외 계층이다.

데이터 접근 예외의 최상위 예외는 DataAccessException이다.

모두 RuntimeException인 것을 알 수 있다.

참고로..

Transient : 재시도하면 성공 가능성이 있는 예외이다. (쿼리 타임아웃, 락 관련 오류)

NonTransient : 재시도해도 성공할 수 없다. (문법 오류 등)

 

 

sql-error-codes.xml 내용 중 일부이다.

MySQL DB와 Oracle DB에서 동일하게 중복 키가 원인인 에러이지만,

error code는  1062, 1로 상이하며,

하지만.. duplicateKeyCodes로 동일한 프로퍼티로 처리 되며

이는 DuplicateKeyCodes라는 예외로 일관성 있게 변환해 줄 수 있다.

(변환기 인터페이스 : SQLExceptionTranslator )

 

사용 예시..

SQLExceptionTranslator의 구현체인

SQLErrorCodeSQLExceptionTranslator를 생성자에서 만들고있다.

어떤 DB를 사용하는지 알기 위해 dataSource를 생성자 파라미터로 들어간다.

 

catch 구문에서

SQLException을 잡아서 처리하는데..

예외 변환기로 다른 DB가 적용되더라도 일관된 예외를 생성할 수 있도록 하였다.

파라미터로는..

1번 : 현재 어떤 작업인지..

2번 : 수행한 sql

3번 : 원본 예외

가 들어간다.