[Spring 3.1] 데이터 엑세스 기술

 

 

 

스프링은 보통 JDBC API를 사용해 데이터베이스와 연결해서 동작하고, 데이터 접근을 위한 여러 가지 추상화와 통합 기술을 지원한다.

 

JPA, Spring Data JPA, MyBatis 등... 데이터 엑세스 관련 다양한 기술들이 있지만, 모두 내부적으로 JDBC API를 사용하고 있다. (추상화 되어 있어 개발자는 해당 기술이 JDBC API를 사용하고 있는지 알 필요는 없다)

 

100명의 사용자가 스프링으로 구축한 서버에 접속한다고 생각해 보자.

스프링 애플리케이션은 실행될 때 미리 빈들을 등록하고 주입하는 역할을 수행하고, 미리 주입된 빈들을 사용해서 사용자의 요청을 처리한다.

 

주입된 빈의 스코프가 싱글톤이라고 해 보자.

싱글톤 스코프를 가지는 빈은 애플리케이션 컨텍스트 내부에서 한 번만 생성하고 관리하게 되니, 100명이 요청을 하더라도 처음에 만들어 둔 하나의 빈으로 요청을 처리한다. 

 

즉, 100명이 동시에 요청을 진행하면 Tomcat이 요청을 처리하기 위한 적당한 양의 쓰레드를 할당하고 활성화된 쓰레드의 개수만큼의 작업을 동시에 수행하고, 하나의 빈으로 요청을 처리하게 된다. (최대 개수를 초과하면 요청을 대기열에 추가한다)

 

요청을 처리하는 중 데이터베이스 커넥션이 필요한 경우가 있다.

데이터베이스 커넥션은 오버헤드를 줄이기 위해 커넥션 풀에서 관리되고, 애플리케이션이 시작될 때 정해진 개수만큼 커넥션이 만들어진 후 커넥션 풀에 저장된다. (커넥션 풀의 크기는 쓰레드 풀의 크기와 비슷하게 설정한다)

 

커넥션은 쓰레드가 요청을 처리한 후 커넥션 풀에 반환되고 다른 쓰레드가 반환한 커넥션을 받아서 사용한다.

 

커넥션 풀 관련 설정은 WAS 또는 애플리케이션 레벨 (주로 부트) 에서 처리하고, properties 파일 또는 yml 파일으로 설정을 진행한다.

 

JDBC API는 데이터 액세스 기술의 기본이 되는 로우레벨의 API으로, 커넥션 풀에 넣어 둘 데이터베이스 커넥션을 만들 때도 JDBC API가 사용된다.

 

(jdbc api 설명 게시글 링크.. 지난번에 쓴거 있을거임 )

 

 

 

MyBatis

 

 

iBatis 3 버전 이후 버전을 MyBatis라고 부른다.

자바 객체와 SQL 구문간의 매핑을 지원하고 SQL을 xml 파일로 따로 빼서 관리할 수 있어 편리하다.

 

설정xml과 매핑xml로 구분된다.

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="HBYS">
	<select id="selectMiHbys" resultType="casemap">
		SELECT  H.HBYSKEY,
			    H.SJYEOBU,
			    H.MIYEOBU
		   FROM TB_HBYS H
		  WHERE H.SJYEOBU = "N"
		  AND H.MIYEOBU = "Y"
	</select>
	
	<update id="updateMiHbys">
		UPDATE TB_HBYS
		   SET MIYEOBU = 'N'
		 WHERE HBYSKEY  = #{hbyskey}
	</update>
</mapper>

 

 

매핑 xml 에는 사용할 SQL 구문과 파라미터, 실행 결과를 어떻게 자바 객체로 변환하는지가 담겨있다.

 

 

JPA

 

 

Java Persistent API의 약자로 영속성 관리와 ORM을 위한 기술이다.

 

자바 오브젝트와 관계형 데이터베이스간의 변환을 쉽게 처리해주는 기술으로, 미리 준비된 매핑정보를 바탕으로 SQL을 생성 후 데이터베이스에 전달한 후 결과를 받아오는 방식으로 동작한다.

 

JPA는 인터페이스이고, 그 구현체로 하이버네이트, OpenJPA 등 여러가지가 있지만 하이버네이트를 가장 많이 사용한다.

 

EntityManager인터페이스를 구현한 오브젝트를 사용해 JPA Persistence Context 에 접근하고 엔티티 인스턴스를 관리한다.

 

JPA도 내부적으로 JDBC API를 사용해서 데이터베이스와 연결한다.

 

 

 

Transaction

 

 

스프링이 제공하는 선언적 트랜잭션을 사용하면 기존 코드에 전혀 영향을 주지 않으면서 트랜잭션 기능을 구현할 수 있다.

트랜잭션 설정은 AOP로 진행되고 네임스페이스를 활용하는 방법과 @Transactional 애너테이션을 사용하는 방법이 있다.

 

@Transactional 애너테이션을 사용할 때는 설정파일에 명시적으로 포인트컷과 어드바이스를 정의하지 않아도 된다.

 

트랜잭션 속성

 

REQUIRED : 기본 속성으로 트랜잭션이 있으면 참여하고 없으면 새로 시작한다.

SUPPOERTS : 있으면 참여하고 없으면 트랜잭션 없이 진행한다.

MANDATORY : 있으면 참여하고 없으면 예외를 뱉는다. 혼자 실행되면 안 되는 경우 사용하자.

REQUIRES_NEW : 항상 새로 시작한다. 있으면 잠시 보류시킨다.

NOT_SUPPORT : 있으면 보류시키고 트랜잭션 없이 진행한다.

NEVER : 있으면 예외를 뱉는다. 트랜잭션을 쓰지 않도록 강제한다.

NESTED : 있으면 중첩 트랜잭션을 시작한다. (트랜잭션 내부의 트랜잭션)

 

트랜잭션 격리 수준

 

DEFAULT : DB 엔진이나 데이터 액세스 기술의 설정을 따라간다. 

READ_UNCOMMITTED : 커밋 전에 변경 결과가 다른 트랜잭션에 노출된다. 가장 빠르다.

READ_COMMITTED : 가장 많이 사용된다. 커밋하지 않은 정보는 노출되지 않는다.

REPEATABLE_READ : 트랜잭션이 읽은 로우를 다른 트랜잭션이 수정하는 작업을 막는다. (추가는 막지 않는다)

SERIALIZABLE : 트랜잭션을 순차적으로 진행시킨다. 안전하지만 성능이 떨어진다.

 

그 외 속성

 

timeout : 트랜잭션에 제한시간을 설정한다. 

readOnly : 트랜잭션을 읽기 전용으로 설정한다. 성능 최적화에 사용된다.

rollbackFor : 기본 동작방식을 바꾼다. 체크 예외가 발생했을 때 롤백시킬 수 있다.

noRollbackFor : 기본 동작방식을 바꾼다. 런타임 예외가 발생했을 때 커밋할 수 있다.

 

 

스프링은 트랜잭션 매니저를 빈으로 등록하고 선언적 트랜잭션에서 사용한다.

 

빈의 이름은 transactionManager이고, 트랜잭션 매니저는 하나만 사용되니 데이터 액세스 기술을 여러 개 사용하는 경우 적절한 클래스를 트랜잭션 매니저로 등록해서 사용하자. 

 

특히 ORM 기술과 비 ORM 기술을 하나의 트랜잭션으로 묶어서 처리하는 경우 두 기술을 제대로 이해한 후 사용하자.