[스프링프레임워크] transaction, rollback, jndi

트랜잭션(TRANSACTION)

TRANSACTION의 시작

  - 실행 가능한 SQL문장이 제일 처음 실행될 때

TRANSACTION의 종료

COMMIT이나 ROLLBACK/ DDL이나 DCL문장의 실행(자동 COMMIT)/기계 장애 또는 시스템 충돌(crash)/ deadlock 발생/사용자가 정상 종료

자동 COMMIT은 다음의 경우 발생 한다.

 DDL,DCL문장이 완료 될 때/ 명시적인 COMMIT이나 ROLLBACK없이 SQL*Plus를 정상 종료 했을 경우

자동 ROLLBACK은 다음의 경우 발생 한다.

  - SQL*Plus를 비정상 종료 했을 경우/  - 비정상적인 종료, system failure

COMMIT과 ROLLBACK

  - COMMIT : 변경사항 저장/  - ROLLBACK : 변경사항 취소

COMMIT과 ROLLBACK의 장점

  - 데이터의 일관성을 제공 한다.

  - 데이터를 영구적으로 변경하기 전에 데이터 변경을 확인하게 한다.

  - 관련된 작업을 논리적으로 그룹화 할 수 있다.

  - COMMIT, SAVEPOINT, ROLLBACK 문장으로 TRANSACTION의 논리를 제어할 수 있다.

COMMIT이나 ROLLBACK 이전의 데이터 상태

  - 데이터 이전의 상태로 북구가 가능 하다.

  - 현재 사용자는 SELECT문장으로 DML작업의 결과를 확인할 수 있다.

  - 다른 사용자는 SELECT문장으로 현재 사용자 사용한 DML문장의 결과를 확인할 수 없다.

  - 변경된 행은 LOCK이 설정 되어서 다른 사용자가 변경 할 수 없다.

COMMIT 이후의 데이터 상태

  - 데이터베이스에 데이터를 영구적으로 변경

  - 데이터의 이전 상태는 완전히 상실

  - 모든 사용자가 결과를 볼 수 있다.

  - 변경된 행의 LOCK이 해제되고 다른 사용자가 변경할 수 있다.

  - 모든 SAVEPOINT는 제거 된다.

1) COMMIT과 ROLLBACK

Ÿ  COMMIT

o  모든 작업을 정상적으로 처리하겠다고 확정하는 명령어이다.

o  트랜젝션의 처리 과정을 데이터베이스에 반영하기 위해서, 변경된 내용을 모두 영구 저장한다.

o  COMMIT 수행하면, 하나의 트랜젝션 과정을 종료하게 된다.

o  TRANSACTION(INSERT, UPDATE, DELETE)작업 내용을 실제 DB에 저장한다.

o  이전 데이터가 완전히 UPDATE된다.

o  모든 사용자가 변경한 데이터의 결과를 볼 수 있다.

Ÿ  ROLLBACK

o  작업 중 문제가 발생했을 때, 트랜젝션의 처리 과정에서 발생한 변경 사항을 취소하고, 트랜젝션 과정을 종료시킨다.

o  트랜젝션으로 인한 하나의 묶음 처리가 시작되기 이전의 상태로 되돌린다.

o  TRANSACTION(INSERT, UPDATE, DELETE)작업 내용을 취소한다.

o  이전 COMMIT한 곳까지만 복구한다.

Ÿ  트랜젝션 작업 중 하나라도 문제가 발생하면, 모든 작업을 취소해야 하기 때문에 하나의 논리적인 작업 단위로 구성해 놓아야 한다.

o  문제가 발생하면, 논리적인 작업의 단위를 모두 취소해 버리면 되기 때문이다.

Ÿ  COMMIT 명령어와 ROLLBACK 명령어의 장점

o  데이터 무결성이 보장된다.

o  영구적으로 변경하기 전에 데이터의 변경사항을 확인할 수 있다.

o  논리적으로 연관된 작업을 그룹화할 수 있다.

Ÿ  COMMIT 추가 설명

o  TRANSACTION(INSERT, UPDATE, DELETE)작업 내용을 실제 DB에 저장한다.

o  이전 데이터가 완전히 UPDATE된다.

o  모든 사용자가 변경한 데이터의 결과를 볼 수 있다.

Ÿ  ROLLBACK 추가 설명

o  TRANSACTION(INSERT, UPDATE, DELETE)작업 내용을 취소한다.

o  이전 COMMIT한 곳까지만 복구한다.

Ÿ  자동 COMMIT되는 경우

o  SQL*PLUS가 정상 종료된 경우

o  DDL과 DCL 명령문이 수행된 경우

Ÿ  자동 ROLLBACK되는 경우

o  SQL*PLUS가 비정상 종료된 경우

o  정전이 발생했거나 컴퓨터 DOWN된 경우

transactionManager

마이바티스는 두가지 타입의 TransactionManager를 제공한다.

  JDBC - 이 설정은 간단하게 JDBC 커밋과 롤백을 처리하기 위해 사용된다. 트랜잭션의 스코프를 관리하기 위해 dataSource 로 부터 커넥션을 가져온다.

  MANAGED - 이 설정은 어떤것도 하지 않는다. 결코 커밋이나 롤백을 하지 않는다. 대신 컨테이너가 트랜잭션의 모든 생명주기를 관리한다. 디플트로 커넥션을 닫긴 한다. 하지만 몇몇 컨테이너는 커넥션을 닫는 것 또한 기대하지 않기 때문에 커넥션 닫는 것으로 멈추고자 한다면 “closeConnection”프로퍼티를 false로 설정하라. 예를들면:

<transactionManager type="MANAGED"><property name="closeConnection" value="false"/></transactionManager>

typeAliases

타입 별칭은 자바 타입에 대한 짧은 이름이다. 오직 XML 설정에서만 사용되며, 타이핑을 줄이기 위해 존재한다. 예를들면:

<typeAliases><typeAlias alias="Author" type="domain.blog.Author"/><typeAlias alias="Blog" type="domain.blog.Blog"/><typeAlias alias="Comment" type="domain.blog.Comment"/><typeAlias alias="Post" type="domain.blog.Post"/><typeAlias alias="Section" type="domain.blog.Section"/><typeAlias alias="Tag" type="domain.blog.Tag"/></typeAliases>

이 설정에서 “Blog”는 여러군데에서 “domain.blog.Blog” 대신 사용할 수 있다.

마이바티스가 빈을 찾도록 패키지를 명시할 수 있다. 예를들면:

<typeAliases><package name="domain.blog"/></typeAliases>

domain.blog 에서 빈을 검색하고 애노테이션이 없을 경우 빈의 이름이 소문자로 변환된 형태의 별칭으로 등록할 것이다. 이때 빈의 패키지정보도 제거하고 등록된다. 이를테면 domain.blog.Author는 author로 등록될 것이다.

dataSource

dataSource엘리먼트는 표준 JDBC DataSource인터페이스를 사용하여 JDBC Connection객체의 소스를 설정한다.

  대부분의 마이바티스 애플리케이션은 예제처럼 dataSource를 설정할 것이다.

여기엔 3 가지의 내장된 dataSource타입이 있다.

UNPOOLED - 이 구현체는 매번 요청에 대해 커넥션을 열고 닫는 간단한 DataSource이다. 조금 늦긴 하지만 성능을 크게 필요로 하지 않는 간단한 애플리케이션을 위해서는 괜찮은 선택이다. UNPOOLED DataSource는 5 개의 프로퍼티만으로 설정한다.

  driver - JDBC드라이버의 패키지 경로를 포함한 결제 자바 클래스명

  url - 데이터베이스 인스턴스에 대한 JDBC URL

  username - 데이터베이스에 로그인 할 때 사용할 사용자명

  password - 데이터베이스에 로그인 할 때 사용할 패스워드

  defaultTransactionIsolationLevel - 커넥션에 대한 디폴트 트랜잭션 격리 레벨

필수는 아니지만 선택적으로 데이터베이스 드라이버에 프로퍼티를 전달할 수도 있다. 그러기 위해서는 다음 예제처럼 “driver.” 로 시작하는 접두어로 프로퍼티를 명시하면 된다.

  driver.encoding=UTF8

이 설정은 “encoding” 프로퍼티를 “UTF8”로 설정하게 된다. 이 방법외에도 DriverManager.getConnection(url, driverProperties)메소드를 통해서도 프로퍼티를 설정할 수 있다.

POOLED - DataSource에 풀링이 적용된 JDBC 커넥션을 위한 구현체이다. 이는 새로운 Connection 인스턴스를 생성하기 위해 매번 초기화하는 것을 피하게 해준다. 그래서 빠른 응답을 요구하는 웹 애플리케이션에서는 가장 흔히 사용되고 있다.

UNPOOLED DataSource에 비해 많은 프로퍼티를 설정할 수 있다.

  poolMaximumActiveConnections - 주어진 시간에 존재할 수 있는 활성화된(사용중인) 커넥션의 수. 디폴트는 10이다.

  poolMaximumIdleConnections - 주어진 시간에 존재할 수 있는 유휴 커넥션의 수

  강제로 리턴되기 전에 풀에서 “체크아웃” 될 수 있는 커넥션의 시간. 디폴트는 20000ms(20 초)

  poolTimeToWait - 풀이 로그 상태를 출력하고 비정상적으로 긴 경우 커넥션을 다시 얻을려고 시도하는 로우 레벨 설정. 디폴트는 20000ms(20 초)

  poolMaximumLocalBadConnectionTolerance – 이것은 모든 쓰레드에 대해 bad Connection이 허용되는 정도에 대한 낮은 수준의 설정입니다. 만약 쓰레드가 bad connection 을 얻게 되어도 유효한 또 다른 connection 을 다시 받을 수 있습니다. 하지만 재시도 횟수는 poolMaximumIdleConnections 과 poolMaximumLocalBadConnectionTolerance 의 합보다 많아야 합니다. 디폴트는 3이다. (3.4.5 부터)

  poolPingQuery - 커넥션이 작업하기 좋은 상태이고 요청을 받아서 처리할 준비가 되었는지 체크하기 위해 데이터베이스에 던지는 핑쿼리(Ping Query). 디폴트는 “핑 쿼리가 없음” 이다. 이 설정은 대부분의 데이터베이스로 하여금 에러메시지를 보게 할수도 있다.

  poolPingEnabled - 핑쿼리를 사용할지 말지를 결정. 사용한다면 오류가 없는(그리고 빠른) SQL 을 사용하여 poolPingQuery 프로퍼티를 설정해야 한다. 디폴트는 false 이다.

  poolPingConnectionsNotUsedFor - poolPingQuery가 얼마나 자주 사용될지 설정한다. 필요이상의 핑을 피하기 위해 데이터베이스의 타임아웃 값과 같을 수 있다. 디폴트는 0이다. 디폴트 값은 poolPingEnabled가 true일 경우에만 모든 커넥션이 매번 핑을 던지는 값이다.

JNDI - 이 DataSource 구현체는 컨테이너에 따라 설정이 변경되며 JNDI 컨텍스트를 참조한다. 이 DataSource 는 오직 두개의 프로퍼티만을 요구한다.

  initial_context - 이 프로퍼티는 InitialContext 에서 컨텍스트를 찾기(예를 들어 initialContext.lookup(initial_context))위해 사용된다. 이 프로퍼티는 선택적인 값이다. 이 설정을 생략하면 data_source프로퍼티가 InitialContext에서 직접 찾을 것이다.

  data_source - DataSource인스턴스의 참조를 찾을 수 있는 컨텍스트 경로이다. initial_context 룩업을 통해 리턴된 컨텍스트에서 찾을 것이다. initial_context 가 지원되지 않는다면 InitialContext 에서 직접 찾을 것이다.