DAO 구현 기술 

Sean C. Sullivan 
소프트웨어 엔지니어
2003년 10월 7일

J2EE 개발자들은 Data Access Object (DAO) 디자인 패턴을 사용하여 저수준의 데이터 액세스 로직과 고급 비즈니스 로직을 분리한다. DAO 패턴을 구현하는 것은 단순히 데이터 액세스 코드를 작성하는 것 이상이다.

지난 18개월 동안, 재능 있는 소프트웨어 엔지니어들과 함께 웹 기반의 공급체인 관리 애플리케이션을 구현했다. 우리가 만든 애플리케이션은 선적 상황, 공급 체인 메트릭스, 창고 재고, 운송장, 프로젝트 관리 데이터, 사용자 프로파일 등의 광범위한 데이터에 접근했다. JDBC API를 사용하여 회사의 다양한 데이터베이스 플랫폼에 연결했고 이 애플리케이션에 DAO 디자인 패턴을 적용했다.

그림 1은 애플리케이션과 데이터 소스의 관계이다:

그림 1. 애플리케이션과 데이터 소스

DAO의 기초
DAO 패턴은 표준 J2EE 디자인 패턴들 중 하나이다. 이 패턴을 사용하여 저수준 데이터 액세스와 고급 비지니스 로직을 분리한다. 전형적인 DAO 구현에는 다음과 같은 요소들이 있다:

• DAO 팩토리 클래스
• DAO 인터페이스
• DAO 인터페이스를 구현하는 구체적 클래스
• 데이터 전송 객체들(밸류(value) 객체)

구체적인 DAO 클래스에는 특정 데이터 소스로 부터 데이터에 액세스하는데 쓰이는 로직이 포함되어 있다.

트랜잭션 경계설정(demarcation)
DAO는 트랜잭션 객체들이라는 것을 반드시 기억해야 한다. DAO에 의해 수행되는 각각의 작동(데이터 구현, 업데이트, 삭제)은 트랜잭션과 관련있다. 따라서 트랜잭션 경계설정(demarcation) 개념은 매우 중요하다.

트랜잭션 경계설정은 트랜잭션 영역들이 정의 되는 방식이다. J2EE 스팩은 두 가지 모델의 트랜잭션 경계설정을 설명하고 있다. (표 1):

표 1. 트랜잭션 경계설정

프로그램에 입각한(Programmatic) 트랜잭션 경계설정을 중점적으로 설명하겠다.

디자인 고려사항
앞서 언급했지만, DAO는 트랜잭션 객체이다. 전형적인 DAO는 구현, 업데이트, 삭제 같은 트랜잭션 작동을 수행한다. DAO를 설계할 때 다음 사항들을 점검한다:

• 트랜잭션은 어떻게 시작하는가?
• 트랜잭션은 어떻게 끝나는가?
• 트랜잭션 시작을 담당하는 객체는 무엇인가?
• 트랜잭션 종료를 담당하는 객체는 무엇인가?
• DAO가 트랜잭션의 시작과 종료를 담당해야 하는가?
• 이 애플리케이션이 다중의 DAO를 통해 데이터에 액세스해야 하는가?
• 트랜잭션에 포함될 DAO의 수는?
• 하나의 DAO가 또 DAO에 대한 메소드를 호출할 수 있는가?

이러한 질문들에 대한 답을 알고있다면 자신의 DAO에 가장 잘 맞는 트랜잭션 경계설정 전략을 선택하는데 도움이 된다. DAO에는 두 가지 주요한 트랜잭션 경계설정 전략이 있다. 하나는 DAO가 트랜잭션의 경계를 설정하도록 하는 것이다. 또 다른 방법은 트랜잭션 경계설정을 DAO의 메소드를 호출하는 객체에 맡기는 것이다. 전자를 선택한다면 DAO 클래스 안에 트랜잭션 코드를 임베딩해야 한다. 후자의 방법을 선택한다면 트랜잭션 경계설정 코드는 DAO 클래스의 외부에 있게 될 것이다. 코드 예제를 보고 이 두 가지 방법을 자세히 보도록 하자.

Listing 1- DAO와 두 개의 데이터 작동;구현 및 업데이트:

Listing 1. DAO 메소드

       public void createWarehouseProfile(WHProfile profile);
       public void updateWarehouseStatus(WHIdentifier id, StatusInfo status);

Listing 2은 간단한 트랜잭션이다. 트랜잭션 경계설정 코드는 DAO 클래스 외부에 있다. 이 예제에서 콜러(caller)가 다중의 DAO 작동들을 이 트랜잭션 내에서 결합하는 방법을 주목해보자.

Listing 2. 콜러(Caller)에 의해 관리되는 트랜잭션

      tx.begin();    // start the transaction
      dao.createWarehouseProfile(profile);
      dao.updateWarehouseStatus(id1, status1);
      dao.updateWarehouseStatus(id2, status2);
      tx.commit();   // end the transaction

이 트랜잭션 경계설정 전략은 단일 트랜잭션에서 다중의 DAO에 액세스 해야하는 애플리케이션에 특별히 어울린다.

JDBC API 또는 Java Transaction API (JTA)를 사용하여 트랜잭션 경계설정을 구현할 수 있다. JDBC 트랜잭션 경계설정은 JTA 보다 단순하다. 하지만 JTA는 보다 유연하다.

JDBC를 이용한 트랜잭션 경계설정
JDBC 트랜잭션은 Connection 객체를 사용하여 제어된다. JDBC Connection 인터페이스(java.sql.Connection)는 두 개의 트랜잭션 모드를 제공한다. (auto-commit과 manual commit). java.sql.Connection은 트랜잭션 제어에 다음의 메소드를 제공한다:

• public void setAutoCommit(boolean)
• public boolean getAutoCommit()
• public void commit()
• public void rollback()

Listing 3은 JDBC API를 사용하여 트랜잭션의 경계설정을 하는 방법이다:

Listing 3. JDBC API를 이용한 트랜잭션 경계설정

      import java.sql.*;
      import javax.sql.*;

      // ...
      DataSource ds = obtainDataSource();
      Connection conn = ds.getConnection();
      conn.setAutoCommit(false);
      // ...
      pstmt = conn.prepareStatement("UPDATE MOVIES ...");
      pstmt.setString(1, "The Great Escape");
      pstmt.executeUpdate();
      // ...
      conn.commit();
      // ...

JDBC 트랜잭션 경계설정을 이용하면 여러 개의 SQL 문장을 하나의 트랜잭션으로 결합할 수 있다. JDBC 트랜잭션의 단점 중 하나는 트랜잭션 범위가 하나의 데이터베이스 연결로 제한되어 있다는 점이다. JDBC 트랜잭션은 다중 데이터베이스로 확장할 수 없다. 다음에는 JTA를 사용한 트랜잭션 경계설정이다.

JTA 개요
Java Transaction API (JTA)와 Java Transaction Service (JTS)는 J2EE 플랫폼에 분산 트랜잭션 서비스를 제공한다. 분산 트랜잭션에는 트랜잭션 매니저와 한 개 이상의 리소스 매니저가 포함된다. 리소스 매니저는 일종의 영속 데이터스토어이다. 트랜잭션 매니저는 모든 트랜잭션 참여자들 간 통신을 조정하는 역할을 담당한다. 트랜잭션 매니저와 리소스 매니저 관계는 다음과 같다. (그림 2):

그림 2. 트랜잭션 매니저와 리소스 매니저

JTA 트랜잭션은 JDBC 트랜잭션 보다 강력하다. JDBC 트랜잭션이 하나의 데이터베이스 연결로 제한되어 있다면 JTA 트랜잭션은 다중의 참여자들을 가질 수 있다. 다음의 자바 플랫폼 컴포넌트 중 어떤 것이든지 JTA 트랜잭션에 참여할 수 있다:

• JDBC 커넥션
• JDO PersistenceManager 객체
• JMS 큐
• JMS 토픽
• Enterprise JavaBeans
• J2EE Connector Architecture 스팩에 호환하는 리소스 어댑터

JTA를 이용한 트랜잭션 경계설정
JTA로 트랜잭션 경계를 설정하기 위해 애플리케이션은 javax.transaction.UserTransaction 인터페이스에 대한 메소드를 호출한다. Listing 4는 UserTransaction 객체의 전형적인 JNDI이다:

Listing 4. UserTransaction 객체의 JNDI

      import javax.transaction.*;
      import javax.naming.*;
      // ...
      InitialContext ctx = new InitialContext();
      Object txObj = ctx.lookup("java:comp/UserTransaction");
      UserTransaction utx = (UserTransaction) txObj;

애플리케이션 UserTransaction 객체에 대한 레퍼런스를 가진 후에 트랜잭션을 시작한다. (Listing 5):

Listing 5. 트랜잭션 시작

      utx.begin();
      // ...
      DataSource ds = obtainXADataSource();
      Connection conn = ds.getConnection();
      pstmt = conn.prepareStatement("UPDATE MOVIES ...");
      pstmt.setString(1, "Spinal Tap");
      pstmt.executeUpdate();
      // ...
      utx.commit();
      // ...

애플리케이션이 commit()을 호출하면, 트랜잭션 매니저는 2 단계 커밋(two-phase commit) 프로토콜을 사용하여 트랜잭션을 종료한다.

트랜잭션 제어용 JTA 메소드
javax.transaction.UserTransaction 인터페이스는 다음의 트랜잭션 제어 메소드를 제공한다:

• public void begin()
• public void commit()
• public void rollback()
• public int getStatus()
• public void setRollbackOnly()
• public void setTransactionTimeout(int)

JTA 트랜잭션을 시작할 때 이 애플리케이션은 begin()을 호출한다. 트랜잭션을 끝내려면 commit() 또는 rollback()을 호출한다. (참고자료).

JTA와 JDBC 사용하기
개발자들은 DAO 클래스에서 저수준 데이터 작동에 JDBC를 사용하곤 한다. JTA를 이용하여 트랜잭션의 경계를 설정하려면 javax.sql.XADataSource, javax.sql.XAConnection, javax.sql.XAResource인터페이스를 구현하는 JDBC 드라이버가 필요하다. 이러한 인터페이스를 구현하는 드라이버는 JTA 트랜잭션에 참여할 수 있게된다. XADataSource 객체는 XAConnection 객체용 팩토리이다. XAConnection는 JTA 트랜잭션에 참여하는 JDBC 커넥션이다.

애플리케이션 서버의 관리 툴을 사용하여 XADataSource를 설정해야 한다. 애플리케이션 서버 문서와 JDBC 드라이버 문서를 참조하라.

J2EE 애플리케이션은 JNDI를 사용하여 데이터 소스를 검색한다. 일단 애플리케이션이 데이터 소스 객체에 대한 레퍼런스를 갖게 되면 이것은 javax.sql.DataSource.getConnection()을 호출하여 데이터베이스로의 커넥션을 획득하게 된다.

XA 커넥션은 비 XA 커넥션과는 다르다. XA 커넥션은 JTA 트랜잭션에 참여하고 있다는 것을 언제나 기억하라. XA 커넥션은 JDBC의 자동 커밋 기능을 지원하지 않는다. 또한 이 애플리케이션은 XA 커넥션 상에서 java.sql.Connection.commit() 또는 java.sql.Connection.rollback()을 호출하지 않는다. 대신 UserTransaction.begin(), UserTransaction.commit(), UserTransaction.rollback()을 사용한다.

최상의 접근방법 선택하기
JDBC와 JTA를 이용한 트랜잭션 경계설정에 대해 이야기했다. 각 접근방식 대로 장점이 있기 때문에 자신의 애플리케이션에 가장 알맞는 것을 선택해야 한다.

최근 많은 프로젝트에서 우리팀은 JDBC API를 사용하여 DAO 클래스를 구현했다. 이 DAO 클래스는 다음과 같이 요약된다:

• 트랜잭션 경계설정 코드는 DAO 클래스 안으로 임베딩된다.
• DAO 클래스는 트랜잭션 경계설정에 JDBC API를 사용한다.
• 콜러가 트랜잭션 경계를 설정할 방법은 없다.
• 트랜잭션 범위는 하나의 JDBC Connection으로 제한된다.

JDBC 트랜잭션이 복잡한 엔터프라이즈 애플리케이션에 언제나 적합한 것은 아니다. 트랜잭션이 다중 DAO 또는 다중 데이터페이스로 확장한다면 다음과 같은 구현 전략이 보다 적합하다:

• 트랜잭션은 JTA로 경계 설정된다.
• 트랜잭션 경계설정 코드는 DAO와 분리되어 있다.
• 콜러가 트랜잭션 경계설정을 담당하고 있다.
• DAO는 글로벌 트랜잭션에 참여한다.

JDBC 접근방법은 간단함이 매력이다. JTA 접근방법은 유연성이 무기이다. 애플리케이션에 따라 구현 방법을 선택해야 한다.

로깅과 DAO
잘 구현된 DAO 클래스는 런타임 작동에 대한 세부사항을 파악하기 위해 로깅(logging)을 사용한다. 예외, 설정 정보, 커넥션 상태, JDBC 드라이버 메타데이터, 쿼리 매개변수 중 어떤 것이든 선택하여 기록해야 한다. 기록은 모든 개발 단계에 유용하다.

로깅 라이브러리 선택하기
많은 개발자들은 단순한 형식의 로깅을 사용한다: System.out.println과 System.err.println. Println 문장은 빠르고 편리하지만 완벽한 로깅 시스템은 제공하지 않는다. 표 2는 자바 플랫폼을 위한 로깅 라이브러리이다:

표 2.자바 플랫폼을 위한 로깅 라이브러리

java.util.logging은 J2SE 1.4 플랫폼을 위한 표준 API이다. Jakarta Log4j가 더 많은 기능성과 유연성을 제공한다는 것에는 많은 개발자들이 동의하고 있다. java.util.logging의 이점 중 하나는 J2SE 1.3과 J2SE 1.4 플랫폼을 지원한다는 것이다.

Jakarta Commons Logging은 java.util.logging 과의 연결 또는 Jakarta Log4j에 사용될 수 있다. Commons Logging은 로깅 추상 레이어로서 애플리케이션을 기저의 로깅 구현에서 고립시킬 수 있다. Commons Logging을 사용하여 설정 파일을 변경하여 기저의 로깅 구현을 바꿀 수 있다. Commons Logging은 Jakarta Struts 1.1과 Jakarta HttpClient 2.0에 사용된다.

로깅 예제
Listing 7은 DAO 클래스에서 Jakarta Commons Logging을 사용하는 방법이다:

Listing 7. Jakarta Commons Logging 

import org.apache.commons.logging.*;

class DocumentDAOImpl implements DocumentDAO
{
      static private final Log log = LogFactory.getLog(DocumentDAOImpl.class);

      public void deleteDocument(String id)
      {
          // ...
          log.debug("deleting document: " + id);
          // ...
          try
          {
              // ... data operations ...
          }
          catch (SomeException ex)
          {
              log.error("Unable to delete document", ex);
              // ... handle the exception ...
  }
      }
}

로깅은 미션 수행에 중요한 애플리케이션의 중요한 일부이다. DAO에서 오류가 생기면 무엇이 잘못되었는지를 이해할 수 있게끔 최고의 정보를 로그가 제공한다. 로깅과 DAO를 결합하면 디버깅과 문제해결은 확실하다.

DAO에서의 예외 핸들링

DAO 패턴을 구현할 때 다음 사항을 자문해보라:

• DAO의 퍼블릭 인터페이스의 메소드들이 검사된 예외를 던지는가?
• 그렇다면 어떤 예외들인가?
• DAO 구현 클래스에서 예외는 어떻게 처리되는가?

DAO 패턴을 작업하는 과정에서 우리 팀은 예외 핸들링에 대한 가이드라인을 개발했다:

• DAO 메소드는 의미있는 예외를 던져야한다.
  
  
• DAO 메소드는 java.lang.Exception을 던져서는 안된다. java.lang.Exception은 너무 일반적이다. 근본 문제에 대한 정보를 제공하지 않을 것이다.
  
  
• DAO 메소드는 java.sql.SQLException 메소드를 던져서는 안된다. SQLException은 저급 JDBC 예외이다. DAO는 JDBC를 나머지 애플리케이션에 노출하는 것이 아니라 JDBC를 캡슐화 해야한다.
  
  
• DAO 인터페이스의 메소드들은 콜러가 예외를 처리할 수 있다고 합리적으로 판단될 때 에만 검사된예외를 던져야 한다. 콜러가 예외를 핸들할 수 없다면 검사되지 않은(런타임) 예외를 던질 것을 고려하라.
  
  
• 데이터 액세스 코드가 예외를 잡으면 이를 무시하지 말아라. 잡힌 예외를 무시하는 DAO는 문제해결에 애를 먹는다.
  
  
• 연쇄 예외를 사용하여 저급 예외를 고급 예외로 트랜슬레이팅 한다.
  
  
• 표준 DAO 예외 클래스를 정의하라. Spring Framework (참고자료)은 사전 정의된 DAO 예외 클래스를 제공한다.

구현 예제: MovieDAO
MovieDAO는 이 글에 논의된 모든 기술을 보여주는 DAO이다: 트랜잭션 경계설정, 로깅, 예외 핸들링. 코드는 세 개의 패키지로 나뉜다. (참고자료):

• daoexamples.exception
• daoexamples.movie
• daoexamples.moviedemo

DAO 패턴 구현은 클래스와 인터페이스로 구성된다:

• daoexamples.movie.MovieDAOFactory
• daoexamples.movie.MovieDAO
• daoexamples.movie.MovieDAOImpl
• daoexamples.movie.MovieDAOImplJTA
• daoexamples.movie.Movie
• daoexamples.movie.MovieImpl
• daoexamples.movie.MovieNotFoundException
• daoexamples.movie.MovieUtil

MovieDAO 인터페이스는 DAO의 데이터 작동을 정의한다. 이 인터페이스는 다섯 개의 메소드를 갖고 있다:

• public Movie findMovieById(String id)
• public java.util.Collection findMoviesByYear(String year)
• public void deleteMovie(String id)
• public Movie createMovie(String rating, String year, String, title)
• public void updateMovie(String id, String rating, String year, String title)

daoexamples.movie 패키지에는 두 개의 MovieDAO 인터페이스 구현이 포함되어 있다. 각 구현은 트랜잭션 경계설정에 다른 접근방식을 사용한다. (표 3):

표 3. MovieDAO 구현

MovieDAO 데모 애플리케이션
이 데모 애플리케이션 이름은 daoexamples.moviedemo.DemoServlet 이다. DemoServlet은 Movie DAO를 사용하여 무비 데이터를 쿼리 및 업데이트 한다.

Listing 8은 싱글 트랜잭션 에서의 JTA-aware MovieDAO와 Java Message Service의 결합 방법이다.

Listing 8. MovieDAO와 JMS 코드 결합

  UserTransaction utx = MovieUtil.getUserTransaction();
  utx.begin();
  batman = dao.createMovie("R",
      "2008",
      "Batman Reloaded");
  publisher = new MessagePublisher();
  publisher.publishTextMessage("I'll be back");
  dao.updateMovie(topgun.getId(),
      "PG-13",
      topgun.getReleaseYear(),
      topgun.getTitle());
  dao.deleteMovie(legallyblonde.getId());
  utx.commit();

데모를 실행하려면 XA 데이터소스와 비 XA 데이터소스를 애플리케이션 서버에 설정해야 한다. 그런다음 daoexamples.ear 파일을 전개한다.

출처 -http://lbass.tistory.com/entry/%EB%B3%B8%EB%AC%B8%EC%8A%A4%ED%81%AC%EB%9E%A9-%EA%B3%A0%EA%B8%89-DAO-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

트랜잭션은 비즈니스의 통합된 일부입니다. 일반 비즈니스 트랜잭션은 두 개 이상의 관련 부분 사이 자산 이동과 관련되어 있습니다. 정확성을 요하는 기록은 보통 하나 이상의 데이터베이스에 저장됩니다. 이 정보는 비즈니스 작업에 꼭 필요하기 때문에 항상 유효하고, 현재성을 가지고, 신뢰할 수 있어야 합니다. 초보 프로그래머에게는 트랜잭션 처리가 어려울 수 있습니다. J2EE 플랫폼은 종속 가능한 트랜잭션 처리 응용 프로그램 전개를 쉽게 해주는 여러 추상적 개념을 제공합니다. 이 장에서는 Sun ONE Application Server의 J2EE 트랜잭션 및 트랜잭션 지원을 설명합니다.

이 장에서는 일반적으로 Java 트랜잭션, 구체적으로는 Sun ONE Application Server에 포함되어 있는 트랜잭션 지원에 대해 설명합니다.

이 장에서는 다음 내용을 설명합니다.

• 트랜잭션 정보
• J2EE 트랜잭션
• 트랜잭션 자원 관리자
• 로컬 및 분산 트랜잭션
• 컨테이너 관리 트랜잭션
• Bean 관리 트랜잭션
• 트랜잭션 서비스 관리

트랜잭션 정보

---

비즈니스 트랜잭션을 에뮬레이트하려면 프로그램이 여러 단계를 수행해야 할 수 있습니다. 예를 들어, 재무 프로그램이 다음 의사 코드에 나열된 단계를 수행하면 자금을 수표 계좌에서 예금 계좌로 이체할 수 있습니다.

begin transaction

debit checking account

credit savings account

update history log

commit transaction

앞의 의사 코드에서 begin 및 commit 명령은 트랜잭션 경계를 표시합니다. 트랜잭션을 완료하려면 세 단계가 모두 완료되어야 합니다. 세 단계가 모두 완료되지 못하면 데이터 통합이 손상될 수 있습니다.

이 보장을 원자성이라고 합니다. 트랜잭션은 commit 또는 rollback 명령으로 끝납니다. 트랜잭션을 완결하면 트랜잭션 경계 내의 명령으로 수행한 모든 수정이 저장 및 지속됩니다. 변경은 영구적이며 이후 시스템 장애가 일어나도 그대로 유지됩니다. 트랜잭션 내의 명령 중 하나라도 실패하면 트랜잭션 전체가 롤백하며, 그 때까지 트랜잭션 내에서 실행된 모든 명령은 취소됩니다. 예를 들어, 의사 코드의 credit 단계 중 디스크 드라이브에 오류가 발생하면, 트랜잭션은 롤백되고 debit 명령으로 수행되었던 데이터 변경도 모두 취소됩니다.

트랜잭션이 실패해도 트랜잭션 계정 잔액은 여전히 유지되기 때문에 데이터 통합이 손상되지 않습니다. 트랜잭션 작동의 이런 측면을 트랜잭션 일관성이라 합니다.

트랜잭션 서비스는 고립화도 제공합니다. 이것은 트랜잭션이 완결 또는 롤백되기 전까지는 트랜잭션 내 구문을 다른 응용 프로그램에서 관찰할 수 없음을 의미합니다. 일단 트랜잭션이 완결되면 이 완결된 트랜잭션은 응용 프로그램 및 스레드가 안전하게 관찰할 수 있습니다.

J2EE 트랜잭션

---

J2EE의 트랜잭션 처리는 트랜잭션 관리자, 응용 프로그램 서버, 자원 관리자, 자원 어댑터 및 사용자 응용 프로그램의 다섯 참가자에 의해 수행됩니다. 각 엔티티는 다음에서 설명하는 여러 API 및 기능을 구현하여 신뢰할 수 있는 방법으로 트랜잭션을 처리합니다.

• 트랜잭션 관리자는 트랜잭션 구분, 트랜잭션 자원 관리, 동기화 및 트랜잭션 컨텍스트 전파 지원에 필요한 서비스 및 관리 기능을 제공합니다.
• 응용 프로그램 서버는 트랜잭션 상태 관리 등의 응용 프로그램 런타임 환경 지원에 필요한 기반 구조를 제공합니다.
• 자원 관리자(자원 어댑터를 통한)는 응용 프로그램에게 자원에 대한 액세스를 제공합니다. 자원 관리자는 트랜잭션 관리자가 트랜잭션 연결, 트랜잭션 완료 및 복구 작업과 통신할 때 사용하는 트랜잭션 자원 인터페이스를 구현하여 분산된 트랜잭션에 참여합니다. 이런 자원 관리자의 예로 관계형 데이터베이스 서버를 들 수 있습니다.
• 자원 어댑터는 응용 프로그램 서버 또는 클라이언트가 자원 관리자와의 연결에 사용하는 시스템 수준 소프트웨어 라이브러리입니다. 자원 어댑터는 일반적으로 자원 관리자마다 따로 지정됩니다. 자원 어댑터는 라이브러리로 사용 가능하며 이것을 사용하는 클라이언트 주소 공간 내에서 사용됩니다. 이런 자원 어댑터의 예로는 JDBC 드라이버가 있습니다.
• J2EE 응용 프로그램 서버 환경에서 작업하기 위해 개발된 트랜잭션 사용자 응용 프로그램은 JNDI를 사용하여 트랜잭션 데이터 소스 및 선택적으로 트랜잭션 관리자를 조회합니다. EJB의 선언적 트랜잭션 속성 설정 또는 명시적인 프로그램형 트랜잭션 구분을 사용할 수 있습니다.

자원 관리자와 자원 어댑터 엔티티는 서로 밀접하게 연관되어 있어서, 자원 관리자라는 용어가 자원 어댑터와 혼용되는 경우도 많습니다.

트랜잭션 자원 관리자

---

다음 트랜잭션 자원 관리자는 J2EE 트랜잭션 내에서 지원됩니다.

• 데이터베이스
• JMS 공급자
• J2EE 커넥터

데이터베이스

가장 자주 접하게 되는 J2EE 응용 프로그램의 트랜잭션 자원 관리자는 데이터베이스입니다. JDBC는 J2EE 구성 요소가 데이터베이스 액세스에 사용하는 API입니다. 데이터베이스 자원은 JDBC 자원으로 구성됩니다. JDBC 자원은 자원 관리자 또는 JDBC 드라이버가 관리합니다. JDBC 드라이버는 로컬 트랜잭션 또는 전역 트랜잭션 및 때로 로컬 및 전역 트랜잭션 모두에 대한 지원을 제공할 수 있습니다.

Sun ONE Application Server는 여러 J2EE 구성 요소의 JDBC 및 트랜잭션 사용을 지원합니다. JDBC 자원의 등록 및 구성 방법에 대한 자세한 내용은 "JDBC 자원 정보"를 참조하십시오. 응용 프로그램 서버는 트랜잭션 연속성 제공(즉 여러 응용 프로그램 구성 요소로부터 트랜잭션 초기화 및 데이터베이스 액세스 수행)을 담당합니다. 예를 들어, 서블릿이 트랜잭션을 시작하고, 데이터베이스를 액세스하고, 동일한 트랜잭션의 일부로 동일한 데이터베이스를 액세스하는 Enterprise Bean을 불러낸 후, 마지막으로 트랜잭션을 완결할 수 있습니다.

JMS 공급자

JMS는 Java Message Service의 약자입니다. JMS 공급자는 메시지 브로커 서비스를 의미하는 J2EE 용어입니다. JMS API는 응용 프로그램 사이에 신뢰할 수 있는 트랜잭션 방식의 교환을 제공합니다. 트랜잭션 JMS 데이터 소스 지원은 J2EE의 필수 기능입니다. JMS 자원 및 JDBC 자원이 함께 동일한 트랜잭션에 사용될 수 있습니다.

Sun ONE Application Server는 Sun ONE 메시지 대기열, 완전한 기능의 JMS 공급자 및 해당 트랜잭션 자원 관리자에 통합됩니다. 이렇게 하면 Sun ONE Application Server가 서블릿, JSP 페이지 및 Enterprise Bean에서 트랜잭션 JMS에 액세스할 수 있습니다. Sun ONE Application Server에 타사 JMS 공급자를 사용할 수도 있습니다. 자세한 내용은 "JMS 서비스 사용"을 참조하십시오.

J2EE 커넥터

Sun ONE Application Server는 트랜잭션 자원 관리자로 XATransaction 모드를 사용하는 자원 어댑터를 지원합니다. 플랫폼에서는 서블릿, JSP 페이지 및 Enterprise Bean에서 자원 어댑터로 트랜잭션 액세스할 수 있어야 합니다. 단일 트랜잭션 내의 여러 응용 프로그램 구성 요소에서 자원 어댑터에 액세스할 수 있습니다. 예를 들어, 서블릿이 트랜잭션을 시작하고, 자원 어댑터를 액세스하고, 동일한 트랜잭션의 일부로 자원 어댑터를 액세스하는 Enterprise Bean을 불러낸 후, 마지막으로 트랜잭션을 완결할 수 있습니다.

로컬 및 분산 트랜잭션

---

한 자원과만 관련 있는 트랜잭션은 로컬 트랜잭션을 사용하여 완료될 수 있습니다. 또한 로컬 트랜잭션은 모든 참여 응용 프로그램 구성 요소가 하나의 프로세스 내에서 실행되어야 합니다. 두 개 이상의 자원 또는 여러 참여 프로세스가 관련된 트랜잭션은 분산 또는 전역 트랜잭션이 될 수 있습니다. 로컬 트랜잭션 최적화는 최적화 전용 자원 관리자를 사용하며, 이것은 J2EE 응용 프로그램에 투명합니다.

트랜잭션 유형은 관련 자원 관리자에 구현된 인터페이스로 판단할 수 있습니다. 예를 들어, javax.sql.DataSource 인터페이스를 구현하는 JDBC 데이터 소스는 로컬 트랜잭션에 참여할 수 있습니다. javax.sql.XADataSource를 구현하는 데이터 소스는 전역 트랜잭션의 일부를 취할 수 있습니다. 일부 JDBC 자원은 두 인터페이스를 모두 구현하며, 이런 JDBC 자원이 Sun ONE Application Server에 등록되어 있으면 Sun ONE Application Server의 구성에 해당 자원의 선호 기능을 표시하는 구성 정보를 추가해야 할 수 있습니다.

로컬 트랜잭션이 더 간단하며 기본적으로 전역 트랜잭션보다 효율적입니다. 변형해야 할 데이터가 여러 데이터 소스에 있을 경우에는 로컬 트랜잭션이 적절하지 않습니다. 때로 몇 개의 데이터 소스가 트랜잭션에 나열되어야 하는지 예측할 수 없는 경우도 있습니다. 이 때문에 실제로는 전역 트랜잭션을 더 많이 사용합니다. 전역 트랜잭션에 사용할 수 있는 몇 가지 성능 개선 최적화가 있습니다.

J2EE는 트랜잭션 내의 여러 Enterprise Bean에 액세스하는 서블릿이나 JSP의 임의 조합을 모두 포함하는 트랜잭션 응용 프로그램을 지원합니다. 각 구성 요소는 하나 이상의 트랜잭션 자원 관리자에 대해 하나 이상의 연결을 가질 수 있습니다. 다음 그림에서, 호출 트리는 여러 Enterprise Bean을 액세스하는 서블릿 또는 JSP에서 시작하며, 이후 다른 Enterprise Bean을 액세스할 수 있습니다. 구성 요소는 연결을 통해 자원 관리자에 액세스합니다.

트랜잭션의 자원에 액세스하는 J2EE 구성 요소

 

예를 들어, 응용 프로그램은 위 그림의 모든 구성 요소가 단일 트랜잭션의 일부로 자원에 액세스해야 할 수도 있습니다. 응용 프로그램 서버 공급자는 이런 시나리오를 지원하는 트랜잭션 기능을 제공해야 합니다.

J2EE 트랜잭션 관리는 플랫 트랜잭션을 지원합니다. 플랫 트랜잭션은 자식(중첩된) 트랜잭션을 가질 수 없습니다.

트랜잭션 복구는 분산 트랜잭션에 있어 중요한 측면입니다. 크리티컬 포인트 동안 자원을 사용할 수 없거나 기타 복구할 수 없는 오류가 발생하면, 분산 트랜잭션의 상태를 모르게 될 수 있습니다. 꼬이거나 완료되지 못한 트랜잭션을 자동 및 수동으로 복구하는 것은 Sun ONE Application Server의 중요한 기능입니다. 자동 트랜잭션 복구는 관리 인터페이스를 사용하여 수행할 수 있습니다. 트랜잭션 복구 제어 방법의 자세한 내용은 "트랜잭션 서비스 관리"를 참조하십시오.

연결(여기에서는 자원과 동의어로 사용됨)은 공유 가능 여부가 표시될 수 있습니다. 공유 불가능한 방법으로 연결을 사용하려는 J2EE 응용 프로그램 구성 요소는 영향을 받는 측에 배포 정보를 제공하여 컨테이너가 연결을 공유하지 못하도록 해야 합니다. 이것이 필요할 수 있는 경우의 예로는 보안 속성, 고립화 수준, 문자 집합 및 로컬화 구성을 변경하는 경우가 포함됩니다.

컨테이너는 공유 불가능으로 표시된 연결을 공유하지 말아야 합니다. 연결이 공유 불가능으로 표시되어 있지 않으면, 이것은 연결이 실제 공유되어 있는지 여부와 상관없이 응용 프로그램에 투명해야 합니다.

J2EE 응용 프로그램 구성 요소는 선택적 전개 설명자 요소 res-sharing-scope를 사용하여 자원 관리자에 대한 연결의 공유 가능 여부를 표시할 수 있습니다. 컨테이너는 전개 관련 정보가 제공되지 않으면 공유 가능한 연결이라고 간주합니다. J2EE 응용 프로그램 구성 요소는 연결 객체를 캐시하여 여러 트랜잭션에서 다시 사용할 수 있습니다. 공유 연결을 제공하는 컨테이너는 이런 캐시된 연결 객체를 투명하게 전환하여(디스패치할 때) 올바른 트랜잭션 범위를 가진 적절한 공유 연결을 가리키도록 해야 합니다.

Enterprise Bean 응용 프로그램을 설계하는 경우, 개발자는 경계 지정 방법을 결정해야 합니다.

컨테이너 관리 트랜잭션

---

컨테이너 관리 트랜잭션이 있는 Enterprise Bean의 경우에는 EJB 컨테이너가 트랜잭션 경계를 설정합니다. Enterprise Bean 유형으로 Session, Entity 또는 Message-Driven을 가진 컨테이너 관리 트랜잭션을 사용할 수 있습니다. 컨테이너 관리 트랜잭션은 Enterprise Bean 코드가 트랜잭션의 경계를 명시적으로 표시하지 않기 때문에 간단하게 배포할 수 있습니다. 이 코드에는 트랜잭션 시작 및 종료 명령이 없습니다.

일반적으로 컨테이너는 Enterprise Bean 메소드가 시작하기 직전에 트랜잭션을 시작하고, 메소드가 종료되기 직전 트랜잭션을 완결합니다. 각 메소드는 단일 트랜잭션에 관련될 수 있습니다. 한 메소드 내에 중첩된 트랜잭션 또는 여러 트랜잭션을 허용하지 않습니다.

컨테이너 관리 트랜잭션이 트랜잭션에 연결될 때 모든 메소드가 필요하지는 않습니다. Bean을 배포할 때에는 트랜잭션 속성을 설정하여 트랜잭션과 관련된 Bean의 메소드를 지정합니다.

이 절에서는 다음 내용을 설명합니다.

• 트랜잭션 속성
• 트랜잭션 속성 설정
• 컨테이너 관리 트랜잭션 롤백
• Session Bean의 인스턴스 변수 동기화
• 컨테이너 관리 트랜잭션에 허용되지 않는 메소드

트랜잭션 속성

트랜잭션 속성은 트랜잭션 범위를 제어합니다. 다음 그림은 범위 제어가 왜 중요한지 보여주고 있습니다. 다이어그램에서, 메소드 A는 트랜잭션을 시작하고 Bean 2의 메소드 B는 트랜잭션을 불러냅니다. 메소드 B가 실행되면 메소드 A가 시작한 트랜잭션 범위 내에서 실행될까요? 아니면 새 트랜잭션으로 실행될까요? 답은 메소드 B의 트랜잭션 속성에 따라 달라집니다.

   
 
트랜잭션 속성

트랜잭션 속성은 다음 값 중 하나를 가질 수 있습니다.

• Required
• RequiresNew
• Mandatory
• NotSupported
• Supports
• Never

Required

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 이 메소드는 클라이언트 트랜잭션 내에서 실행됩니다. 클라이언트가 트랜잭션과 관련되어 있지 않으면, 메소드가 실행되기 전 먼저 컨테이너가 새 트랜잭션을 시작합니다.

Required 속성은 대부분의 트랜잭션에 사용됩니다. 이 때문에 최소한 개발 초기에는 이것을 기본값으로 사용하는 것이 좋습니다. 트랜잭션 속성은 선언적이기 때문에 나중에 쉽게 변경할 수 있습니다.

RequiresNew

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 컨테이너는 다음 단계를 수행합니다.

• 클라이언트의 트랜잭션 일시 중단
• 새 트랜잭션 시작
• 메소드에게 호출 위임
• 메소드 실행 완료 후 클라이언트의 트랜잭션 다시 시작

클라이언트가 트랜잭션과 관련되어 있지 않으면, 메소드가 실행되기 전 먼저 컨테이너가 새 트랜잭션을 시작합니다.

메소드가 새 트랜잭션 내에서 항상 실행되도록 하려면 RequiresNew 속성을 사용해야 합니다.

Mandatory

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 이 메소드는 클라이언트 트랜잭션 내에서 실행됩니다. 클라이언트가 트랜잭션과 관련되어 있지 않으면 TransactionRequiredException이 발생합니다.

Enterprise Bean의 메소드가 클라이언트 트랜잭션을 사용해야 하는 경우 Mandatory 속성을 사용합니다.

NotSupported

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 컨테이너는 이 메소드를 불러내기 전 먼저 클라이언트 트랜잭션을 일시 중단합니다. 메소드가 완료된 다음 컨테이너는 클라이언트 트랜잭션을 다시 시작합니다.

클라이언트가 트랜잭션과 관련되어 있지 않으면, 컨테이너는 메소드가 실행되기 전 새 트랜잭션을 시작하지 않습니다.

트랜잭션이 필요하지 않은 메소드에는 NotSupported 속성을 사용합니다. 트랜잭션 불러내기는 오버헤드가 있기 때문에 이 속성은 성능을 개선할 수 있습니다.

Supports

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 이 메소드는 클라이언트 트랜잭션 내에서 실행됩니다. 클라이언트가 트랜잭션과 관련되어 있지 않으면, 컨테이너는 메소드가 실행되기 전 새 트랜잭션을 시작하지 않습니다.

메소드의 트랜잭션 작업은 다양하기 때문에 Supports 속성은 주의해서 사용해야 합니다.

Never

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 컨테이너는 RemoteException를 발생합니다. 클라이언트가 트랜잭션과 관련되어 있지 않으면, 컨테이너는 메소드가 실행되기 전 새 트랜잭션을 시작하지 않습니다.

속성 요약

다음 표는 트랜잭션 속성의 영향을 요약합니다. T1 및 T2 트랜잭션은 모두 컨테이너로 제어됩니다. T1 트랜잭션은 Enterprise Bean의 메소드를 호출하는 클라이언트와 관련되어 있습니다. 대부분의 경우 클라이언트도 별도의 Enterprise Bean입니다. T2 트랜잭션은 메소드가 실행되기 전 컨테이너에 의해 시작됩니다.

마지말 열의 '없음'이라는 단어는 비즈니스 메소드가 컨테이너가 제어하는 트랜잭션 내에서 실행되지 않음을 표시합니다. 하지만 이런 비즈니스 메소드에 호출된 데이터베이스는 DBMS의 트랜잭션 관리자가 제어할 수 있습니다.

   트랜잭션 속성

트랜잭션 속성	클라이언트 트랜잭션	비즈니스 메소드의 트랜잭션
Required	없음	T2
	T1	T1
RequiresNew	없음	T2
	T1	T2
Mandatory	없음	오류
	T1	T1
NotSupported	없음	없음
	T1	없음
Supports	없음 T1	없음 T1

트랜잭션 속성 설정

트랜잭션 속성은 배포 설명자에 저장되기 때문에 Enterprise Bean 작성, 응용 프로그램 어셈블리 및 배포 등 J2EE 응용 프로그램 전개자의 여러 단계 도중 변경될 수 있습니다. 하지만 Bean 작성시 속성을 지정하는 것은 개발자가 해야 합니다. 속성은 구성 요소를 더 큰 응용 프로그램으로 어셈블리하는 응용 프로그램 개발자만 수정할 수 있어야 합니다. J2EE 응용 프로그램을 배포하는 사람은 트랜잭션 속성을 지정할 책임이 없습니다.

전체 Enterprise Bean 또는 각 메소드에 대해 트랜잭션 속성을 지정할 수 있습니다. 한 속성은 메소드에 대해 지정하고 다른 속성은 Bean에 대해 지정한 경우에는 메소드에 대해 지정한 속성이 우선권을 갖습니다. 각 메소드에 대해 속성을 지정하는 경우 필요한 사항은 Bean 유형에 따라 달라집니다. Session Bean에는 비즈니스 메소드에 정의된 속성이 필요하지만, 생성 메소드에 대해서는 허용하지 않습니다. Entity Bean에는 비즈니스, 생성, 제거 및 검색 메소드에 대한 트랜잭션 속성이 필요합니다. Message-Driven Bean에는 onMessage 메소드에 대한 트랜잭션 속성(Required 또는 NotSupported 중 하나)이 필요합니다.

컨테이너 관리 트랜잭션 롤백

컨테이너 관리 트랜잭션의 롤백에는 두 가지 방법이 있습니다. 먼저 시스템 예외가 발생하면 컨테이너는 자동으로 트랜잭션을 롤백합니다. 두 번째로 EJBContext 인터페이스의 setRollbackOnly 메소드를 불러내서, Bean 메소드가 컨테이너에게 트랜잭션 롤백을 지시할 수 있습니다. Bean이 응용 프로그램 예외를 발생시키면 롤백이 자동으로 실행되지 않아도 setRollbackOnly를 호출하여 초기화할 수 있습니다.

다음 예에서 BankEJB 예의 transferToSaving 메소드는 setRollbackOnly 메소드를 나타내고 있습니다. 수표 계정의 잔액이 마이너스가 되면, transferToSaving은 setRollBackOnly를 불러내고 응용 프로그램 예외(InsufficientBalanceException)를 발생시킵니다. updateChecking 및 updateSaving 메소드는 데이터베이스 테이블을 업데이트합니다. 업데이트에 실패하면 메소드는 SQLException을 발생시키고 transferToSaving 메소드는 EJBException을 발생시킵니다.

EJBException은 시스템 예외기 때문에, 컨테이너는 자동으로 트랜잭션을 롤백합니다. 다음은 transferToSaving 메소드의 코드입니다.

public void transferToSaving(double amount) throws
InsufficientBalanceException {

checkingBalance -= amount;
savingBalance += amount;

if (checkingBalance < 0.00) { 
context.setRollbackOnly();

throw new InsufficientBalanceException(); 
}
try {
updateChecking(checkingBalance);

updateSaving(savingBalance);
} catch (SQLException ex) {
throw new EJBException 
("Transaction failed due to SQLException: " 
+ ex.getMessage());
}
}

컨테이너가 트랜잭션을 롤백하는 경우, 이것은 항상 트랜잭션 내의 SQL 호출로 발생한 데이터 변경을 모두 실행 취소합니다. 하지만 컨테이너는 Entity Bean에서만 인스턴스 변수에 대한 변경을 취소합니다(이 작업은 Entity Bean의 ejbLoad 메소드를 자동으로 호출하여 수행하며, 데이터베이스에서 인스턴스 변수가 로드됨). 롤백이 발생하면 Session Bean은 트랜잭션 내에 변경된 인스턴스 변수를 명시적으로 다시 설정합니다. Session Bean 인스턴스 변수를 다시 설정하는 가장 쉬운 방법은 SessionSynchronization 인터페이스를 구현하는 것입니다.

트랜잭션 ID를 명령줄 인터페이스를 통해 전달하여 트랜잭션을 롤백할 수도 있습니다. 자세한 내용은 "명령줄 인터페이스를 사용한 트랜잭션 관리"를 참조하십시오.

Session Bean의 인스턴스 변수 동기화

SessionSynchronization 인스턴스(선택적)를 사용하면 인스턴스 변수를 데이터베이스 내의 대응하는 값과 동기화할 수 있습니다. 컨테이너는 트랜잭션의 각 주요 단계에서 SessionSynchronization 메소드(afterBegin, beforeCompletion 및 afterCompletion)를 불러냅니다.

afterBegin 메소드는 새 트랜잭션이 시작되었음을 인스턴스에게 알립니다. 컨테이너는 처음으로 트랜잭션 내의 비즈니스 메소드를 불러내기 전에 먼저 afterBegin을 불러냅니다. afterBegin 메소드는 데이터베이스에서 인스턴스 변수를 로드하기에 좋은 위치입니다. 예를 들어, BankBean 클래스는 afterBegin 메소드 내에 checkingBalance 및 savingBalance 변수를 로드합니다.

public void afterBegin() {

System.out.println("afterBegin()");
try {
checkingBalance = selectChecking();
savingBalance = selectSaving();
} catch (SQLException ex) {
throw new EJBException("afterBegin Exception: " +
ex.getMessage());
}
}

컨테이너는 비즈니스 메소드는 완료되었지만 트랜잭션이 완결되기 전에 beforeCompletion 메소드를 불러냅니다. beforeCompletion 메소드는 Session Bean이 트랜잭션을 롤백할 수 있는(setRollbackOnly를 호출하여) 마지막 장소입니다. 아직 인스턴스의 변수 값을 데이터베이스에 업데이트하지 않았다면, Session Bean은 이 작업을 beforeCompletion 메소드에서 수행합니다.

afterCompletion 메소드는 트랜잭션이 완료되었음을 표시합니다. 여기에는 boolean 값의 매개 변수 하나가 있으며, 트랜잭션이 완결되면 true, 트랜잭션이 롤백되면 false 값을 갖습니다. 롤백이 발생하면 Session Bean은 afterCompletion 메소드에서 데이터베이스의 인스턴스 변수를 새로 고칠 수 있습니다.

public void afterCompletion(boolean committed) {

System.out.println("afterCompletion: " + committed);
if (committed == false) {
try {
checkingBalance = selectChecking();
savingBalance = selectSaving();
} catch (SQLException ex) {
throw new EJBException("afterCompletion SQLException:
" + ex.getMessage());
}
}
}

컨테이너 관리 트랜잭션에 허용되지 않는 메소드

컨테이너가 설정한 트랜잭션 경계를 간섭할 수 있는 메소드는 모두 불러낼 수 없습니다. 금지되는 메소드 목록은 다음과 같습니다.

• java.sql.Connection의 완결, setAutoCommit 및 롤백 메소드.
• javax.ejb.EJBContext의 getUserTransaction 메소드.
• javax.transaction.UserTransaction의 모든 메소드.

하지만 Bean 관리 트랜잭션에는 이 메소드들을 사용하여 경계를 설정할 수 있습니다.

Bean 관리 트랜잭션

---

Bean 관리 트랜잭션의 경우, Session 또는 Message-Driven Bean 내의 코드에서 명시적으로 트랜잭션 경계를 표시합니다. Entity Bean은 Bean 관리 트랜잭션을 가질 수 없으며 대신 컨테이너 관리 트랜잭션을 사용해야 합니다. 컨테이너 관리 트랜잭션을 가진 Bean은 필요한 코드가 줄어들지만 한 가지 제한을 갖습니다. 메소드가 실행되면 Bean은 단일 트랜잭션에 관련되거나 아무런 트랜잭션에도 관련되지 않을 수 있습니다. 이 제한 때문에 Bean 코딩이 어려워지는 경우, Bean 관리 트랜잭션 사용을 고려해야 합니다.

다음 의사 코드는 Bean 관리 트랜잭션으로 구할 수 있는 세분화된 제어 종류를 표시합니다. 의사 코드는 여러 조건을 확인하여 비즈니스 메소드 내에서 여러 트랜잭션의 시작 또는 중지 여부를 결정합니다.

begin transaction
...
update table-a
...
if (condition-x)
commit transaction
else if (condition-y)
update table-b
commit transaction
else
rollback transaction
begin transaction
update table-c
commit transaction

트랜잭션 서비스 관리

---

관리 인터페이스 또는 명령줄 인터페이스를 사용하여 트랜잭션을 관리할 수 있습니다.

이 절에는 다음 주제가 포함됩니다.

• 관리 인터페이스를 사용한 트랜잭션 관리
• 명령줄 인터페이스를 사용한 트랜잭션 관리

관리 인터페이스를 사용한 트랜잭션 관리

관리 인터페이스를 사용하여 트랜잭션 모니터링, 로그 수준 설정, 고급 옵션 지정 등을 수행할 수 있습니다.

복구 정책 및 시간 초과와 같은 인스턴스 범위의 트랜잭션 서비스 속성을 제어할 수 있습니다. 여기에서 지정하는 등록 정보 및 구성은 server.xml 파일에 저장됩니다.

트랜잭션 서비스 옵션을 구성하려면 다음 작업을 수행합니다.

1. 관리 인터페이스의 왼쪽 창에서 트랜잭션 구성을 수정할 Sun ONE Application Server 인스턴스 트리를 엽니다.
2. 배포된 J2EE 서비스에서 트랜잭션 서비스를 선택합니다. 관리 인터페이스 오른쪽 창의 그림 트랜잭션 서비스 구성 옵션에 표시된 다음 창이 나타납니다.

   트랜잭션 서비스 구성 옵션

 

3. 트랜잭션에 대한 모니터링을 활성화하려면 "모니터링 활성화" 확인란을 표시합니다. 다음 표는 모니터링될 수 있는 Java Transaction Service 기능을 나열합니다.

   Java Transaction Service의 모니터링 가능한 속성

등록 정보	Type	설명
transactionsCompleted	int	모니터링이 활성화된 후 완료된 트랜잭션 개수
transactionsRolledBack	int	모니터링이 활성화된 후 롤백된 트랜잭션 개수
transactionsRecovered	int	모니터링이 활성화된 후 복구된 트랜잭션 개수
transactionsInFlight	int	현재 처리 중인 트랜잭션 개수
timeStamp	long	통계가 작성된 타임스탬프(밀리초 단위). 이것은 모두 System.getCurrentTimeInMillis()에서 보고합니다.

4. "로그 수준" 드롭다운 목록에서 트랜잭션에 설정할 로그 수준을 선택합니다. 로그 수준 및 통합 방법의 자세한 내용은 "로깅 사용"을 참조하십시오.
5. 서버 재시작시 실패한 트랜잭션을 자동으로 복구하려면 "재시작시 복구" 확인란을 표시합니다. 트랜잭션 완결 프로토콜의 크리티컬 포인트 동안 자원을 사용할 수 없으면, 트랜잭션은 완료되지 못하고 트랜잭션 로그 파일에 남을 수 있습니다. 이 확인란이 표시되어 있으면 서버는 서버 재시작시 오류가 발생한 트랜잭션 복구를 시도합니다. 관련 자원에 여전히 접근할 수 없으면 서버 재시작 시간이 지연될 수 있습니다. 이 확인란은 기본적으로 표시되지 않습니다.
6. 컨테이너 관리 트랜잭션이 있는 Enterprise Bean의 경우, 트랜잭션 시간 초과(초) 등록 정보의 값을 설정하여 트랜잭션 시간 초과 간격을 제어할 수 있습니다.

이 등록 정보의 값이 0으로 설정되면 트랜잭션은 시간 초과되지 않습니다.


"트랜잭션 시간 초과(초)" 필드에 트랜잭션 시간 초과 간격을 지정합니다. 트랜잭션이 지정된 시간 내에 완료되지 않으면 트랜잭션은 롤백됩니다. 이 속성의 값이 0으로 설정되면 트랜잭션은 시간 초과되지 않습니다.

7. "트랜잭션 로그 위치" 필드에 로그 파일을 저장할 디렉토리의 절대 경로를 지정합니다. 새로 지정한 트랜잭션 로그 디렉토리를 적용하려면 서버를 재시작해야 합니다.
8. "발견적 결정" 드롭다운 상자에서 트랜잭션에 적용할 발견적 결정을 선택합니다. 명백한 결과를 결정할 수 없는 경우 표시된 옵션에서 완결 또는 롤백을 선택하여 응용 프로그램 서버에서 복구 도중 의심스러운 트랜잭션의 결과를 결정하는 방법을 지정합니다. 발견적 결정을 롤백으로 설정하면 트랜잭션을 롤백합니다. 이런 트랜잭션을 완결하는 것이 허용되는 경우도 있습니다.
9. "키 포인트 간격(트랜잭션)" 필드에 로그의 키 포인트 작업 사이의 트랜잭션 개수를 지정합니다. 키 포인트 작업은 완료된 트랜잭션의 항목을 제거하고 파일을 압축하여 트랜잭션 로그 파일의 크기를 줄입니다. 이 속성 값이 커지면 트랜잭션 로그 파일이 커지지만, 키 포인트 작업이 줄어들어 성능이 좋아질 수 있습니다. 이 값이 작아지면(예를 들어, 100) 로그 파일이 작아지지만, 키 포인트 작업 빈도가 높아져서 성능이 약간 낮아질 수 있습니다.

명령줄 인터페이스를 사용한 트랜잭션 관리

다음 절에서 설명한 것처럼, CLI (Command Line Interface)를 사용하여 데이터베이스 트랜잭션을 관리 및 모니터링할 수 있습니다.

• 실행 중인 트랜잭션 나열
• 트랜잭션 관리
• 트랜잭션 서비스 고정
• 트랜잭션 모니터링

이 절은 명령줄 인터페이스를 사용한 트랜잭션 관리 및 모니터링 방법을 설명합니다.

실행 중인 트랜잭션 나열

다음 명령은 실행 중인 트랜잭션 데이터를 구할 때 사용됩니다(multimode에 있고 이미 사용자 이름 및 암호를 설정했다고 가정합니다).

- asadmin> get --monitor
<instanceName>.transaction-service.inflight-tx

다중 행 출력은 다음과 같습니다.

Transaction Id State Elapsed Time (ms)

txnid1 Prepared 20

txnid2 Active 100

txnid3 Active 120

... ... ...

트랜잭션 관리

실행 중인 트랜잭션 나열의 예에서는 트랜잭션 ID txn-ids, txnid2 및 txnid3로 트랜잭션을 롤백한다고 가정합니다. 선택한 트랜잭션을 롤백하는 샘플 명령은 다음의 예와 같습니다.

asadmin> set --monitor <instanceName>.transaction-service.rollback-list=txnid2,txnid3

트랜잭션 서비스 고정

트랜잭션 서비스를 고정하려면 다음 명령을 실행합니다.

asadmin> set --monitor <instanceName>.transaction-service.freeze=true

트랜잭션 서비스가 고정되면 응용 프로그램 서비스 내의 트랜잭션 관리자는 모든 실행 중인 트랜잭션이 일시 중단됩니다. 고정은 제품 배포 시스템에서는 권장하지 않습니다.

트랜잭션 서비스를 고정 해제하려면 다음 명령을 실행합니다.

asadmin> set --monitor <instanceName>.transaction-service.freeze=false

트랜잭션 서비스가 다시 동작 중으로 설정되면 시스템은 중단되었던 지점부터 다시 계속합니다. 활성 시스템을 너무 오래 고정 상태로 두면 일부 데이터베이스 연결이 시간 초과되어 트랜잭션이 롤백될 수 있습니다.

트랜잭션 모니터링

실행 중인 트랜잭션 데이터를 포함하여 트랜잭션 데이터를 모니터링하려면 다음 명령을 실행합니다.

asadmin> get --monitor <instanceName>.transaction-service.*

명령을 실행했을 때 활성 트랜잭션이 없으면 다음 출력을 구할 수 있습니다.

total-tx-completed = 5

total-tx-rolledback = 2

total-tx-inflight = 0

isFrozen = false

tx-inflight = No active transactions found.

명령을 실행했을 때 활성 트랜잭션이 있으면 다음 출력을 구할 수 있습니다.

total-tx-completed = 5

total-tx-rolledback = 2

total-tx-inflight = 2

isFrozen = false

tx-inflight =

Transaction Id State Elapsed Time(ms)

txnid1 Prepared 500

txnid2 Active 360

출처 - https://docs.oracle.com/cd/E19957-01/816-6865-10/agjts.html#266545

jQuery plugin이란 것은

이미 instance화 되어진 object인 jQuery object를 확장하여 새로운 function을 만들어서 사용할 수 있게 하는 것을 의미합니다.

이전 강좌에서 배웠듯이 간단하게 instance화된 새로운 함수 명에 새로운 함수를 작성하면 된다고 볼 수 있다.

하지만 jQuery object의 강점중에 하나인 selector로 반환되어져오는 jQuery object를 그대로 사용할 수 있는 형태여야 할 것이다.

그래서 미리 만들어진 방법인 $.fn 이라는 namespace밑에 확장해주면 원하는 결과를 얻을 수 있다.

이렇게 보면 jQuery plugin의 작성이라는 건 굉장히 단순해 보인다. 실제로도 그렇다.

하지만 특정 plugin을 작성하려면 많은 methods, event procedures 그리고 속성 등을 사용할 수 있어야 편리할 것이다.

그래서 jQuery org에서 말하는 plugin 작성법을 기준으로 몇가지를 숙지해 두는 편이 나은 방법인 것과 공유되질 수있는 방법론이 될 것이다.

1. $.fn을 확장하면 $ jQuery object를 활용하여 사용할 수 있는 plugin 작성가능하고 $.fn은 jQuery effin'이라고 읽어라는 군요. 제이쿼리 에핀 이렇게 읽으면 되는 건가?(영어가 편한 언어가 아니라. 아픔이 큽니다.)

2. 외부 코드와 분리해주시기 위해서 self-invating function을 이용하여 작성하자.

3. method의 호출 결과로 반드시 특정 object나 value를 반환해주는 것이 아니라면(왠만하면 그러지 않는 것이 좋을 것다.) jQuery에 chainability(사전에도 없는 말이다.
   굳이 한글로 바꾸자면 연쇄적으로 내지는 연속적으로 호출가능한 형태)를 유지해주자.

4. 동작에 필요한 defaults 값들을 object정의하고 외부에서 받아올 options object을 받아서 $.extend()로 확장하여 사용한다.

5. 하나의 plugin이라도 수많은 methods를 다른 함수로 일일히 작성하지 말고 하나의 plugin함수 안에서 paramter를 받아서 내부에서 분기하도록 하자.

6. bind 등(애매한 표현 등... 하하 이벤트에 procedure를 붙이는 방법이 다른 좋은 방법들과 이슈가 되는 많다고 하니 이렇게 애매하게 표현하는게 상책이죠.)을 통해서 event procedure를 호출하려고 할때에 다른 plugin과 구분하거나 한번에 unbind하기 위해서라도 plugin이름을 활용하여 명명하자.

7. 일반적으로 object의 속성과 비교하면 상이한 점이 꽤나 있다.
   하지만 이 instance화되어져 있는 jQuery의 plugin으로서 마찬가지 instance화되어져 있는 속성이라는 것이 각 개체의 특정 값을 유지하거나 공유하기 위해서라면
   이걸 jQuery에서는 data라고 하고 data메서드를 활용하여 작성한다.
   여기서 마찬가지 하나 data메서드, 결국 하나의 data라는 object인데 그 하위에 plugin과 같은 이름 명명하고 그 하위에  값이나 개체의 형태로 data안에 해당 plugin의 속성을 작성해준다.

위의 방법이 반드시 강제성을 띠는 것은 아니다. 단지 가이드 라인이라고 해야할 것이다.

필요하고 더 나은 방법이 있다면 다른 방식으로 구현하고 그 방법이 실제로 더 나은 방벙이라면 역으로 제시하여 새로운 가이드가 만들어질 수도 있을 것이다.

이제 위의 항목들을 하나 하나 살펴보도록 하자.

1. $.fn을 확장하면 $ jQuery object를 활용하여 사용할 수 있는 plugin 작성가능하고 $.fn은 jQuery effin'이라고 읽어라는 군요. 제이쿼리 에핀 이렇게 읽으면 되는 건가?(영어가 편한 언어가 아니라. 아픔이 큽니다.)

2. 외부 코드와 분리해주시기 위해서 self-invating function을 이용하여 작성하자.

자 그러므로 가장 단순한 형태의 jQuery Plugin 작성형태라고 하면 "(function ($){ $.fn.myplugin = function () { } })($)"이 될 것이다.

3. method의 호출 결과로 반드시 특정 object나 value를 반환해주는 것이 아니라면(왠만하면 그러지 않는 것이 좋을 것다.) jQuery에 chainability(사전에도 없는 말이다.
   굳이 한글로 바꾸자면 연쇄적으로 내지는 연속적으로 호출가능한 형태)를 유지해주자.

그럼 chainability하게 작성하는 방법에 관해서 알아보자.

적절한 예제라고 보기에는 억지가 많지만 작성법만을 보도록 하자.

결국 마지막에 instance화된 자신의 object를 의미하는 this를 반환하면 된다.

4. 동작에 필요한 defaults 값들을 object정의하고 외부에서 받아올 options object을 받아서 $.extend()로 확장하여 사용한다.

5. 하나의 plugin이라도 수많은 methods를 다른 함수로 일일히 작성하지 말고 하나의 plugin함수 안에서 paramter를 받아서 내부에서 분기하도록 하자.

6. bind 등(애매한 표현 등... 하하 이벤트에 procedure를 붙이는 방법이 다른 좋은 방법들과 이슈가 되는 많다고 하니 이렇게 애매하게 표현하는게 상책이죠.)을 통해서 event procedure를 호출하려고 할때에 다른 plugin과 구분하거나 한번에 unbind하기 위해서라도 plugin이름을 활용하여 명명하자.

7. 일반적으로 object의 속성과 비교하면 상이한 점이 꽤나 있다.
   하지만 이 instance화되어져 있는 jQuery의 plugin으로서 마찬가지 instance화되어져 있는 속성이라는 것이 각 개체의 특정 값을 유지하거나 공유하기 위해서라면
   이걸 jQuery에서는 data라고 하고 data메서드를 활용하여 작성한다.
   여기서 마찬가지 하나 data메서드, 결국 하나의 data라는 object인데 그 하위에 plugin과 같은 이름 명명하고 그 하위에  값이나 개체의 형태로 data안에 해당 plugin의 속성을 작성해준다.

먼저 간단하게 table cell 까만 막대기를 그려주는 jQuery plugin을 작성법대로 기본을 잡아주자.

자! 이제 랜덤한 길이로 보이도록 하자.
(참고로 차분히 이해를 돕기 위해서 step별로 하는 것이지 절대로 원고 불리기가 아닙니다. ㅡㅡ;)

자! 그럼 이제 길이과 미리 정해진 색상과 라벨을 할당하고 이에 관한 속성을 만들어 보도록 하겠습니다.

이렇게 만들어진 속성에 해당하는 data로 유지된 value를 event procedure에 활용하는 형태로 마무리해보겠습니다.

출처 - http://www.sqler.com/456517

jQuery:$.extend() 와 $.fn.extend() 의 혼동

.extend() 함수를 사용할 때 하나의 인수를 넘기는 것과 두 개 이상의 인수를 넘기는 것에는 아주 큰 차이가 있습니다.

.extend() 함수가 하나의 객체를 받을 때

선언된 메소드를 jQuery 나 jQuery.fn (jQuery.prototype, 또는 $.fn 이라고 불리죠.) 에 추가시킵니다.

일반적으로 함수를 위해서는 jQuery 객체를 extend 시키고 메소드를 위해서는 jQuery.fn 을 extend 시킵니다. 함수는 DOM 에서 바로 접근이 불가능하고 메소드는 바로 접근이 가능하죠.

다음 예제에서 jQuery.fn 또는 jQuery 객체를 extend 시킬 때 부르는 방식이 달라짐을 눈여겨 보시기 바랍니다.

1. $.fn.extend({
2. myMethod: function(){...}
3. });
4. //jQuery("div").myMethod();
5.  
6. $.extend({
7. myMethod2: function(){...}
8. });
9. //jQuery.myMethod2(); 

.extend() 함수가 2개 이상의 객체를 받을 때

일반적으로 알려진 것 처럼 첫 번째 객체와 두 번째 객체를 병합(merge) 합니다.

1. var defaults = { size: 3 };
2. var options = { height: 6 };
3. var opts = $.extend(defaults, options)
4. // 'defaults' 가 'options' 에 정의된 메소드와 변수들을 받아옵니다.
5. // opts == defaults == { size: 3, height: 6 }
6. // options == { height: 6 };

만약에 첫 번째 객체가 빈 객체라면 메소드와 변수들을 새로운 객체에 추가시킵니다.

만약 여러 개의 객체들을 단 하나의 객체도 변화시키지 않고 새로운 객체에 만들 때 아주 유용합니다.

1. var opts = $.extend( {}, defaults, options);
2. // 'opts' 가 'defaults' 와 'options'에 선언된 모든 메소드와 변수들을 받습니다.
3. // 'defaults' 와 'options' 는 변하지 않습니다.
4. // opts == { size: 3, height: 6 }
5. // defaults == { size: 3 };
6. // options == { height: 6 };

출처 - http://m.blog.naver.com/k_rifle/178134527

함수의 apply(), call() 메서드

From. 프론트엔드 개발자를 위한 자바스크립트 프로그래밍

함수에는 apply()와 call() 두 가지 메서드가 더 있습니다. 이들 메서드는 모두 소유자인 함수를 호출하면서 this를 넘기는데, 결과적으로는 함수 내부에서 this 객체의 값을 바꾸는 것이나 마찬가지입니다. apply() 메서드는 매개변수로 소유자 함수에 넘길 this와 매개변수 배열으로 받습니다. 두 번째 매개변수는 Array의 인스턴스일 수도 있고 arguement 객체일 수도 있습니다. 다음 예제를 보십시오.

이 예제에서 callSum1()은 sum()을 호출하면서 자신의 this와 arguments 객체를 매개변수로 넘겼습니다. callSum2() 역시 sum()을 호출하지만 이번에는 arguments 객체가 아니라 매배변수 배열을 넘겼습니다. 두 함수 모두 올바르게 실행됩니다.

call() 메서드도 apply()와 마찬가지로 동작하지만 매개변수를 전달하는 방식이 다릅니다. this가 첫 번째 매개변수인 점은 똑같지만 call()을 사용할 때는 반드시 다음 예제와 같이 매개변수를 각각 나열해야 합니다.

결과는 apply()와 마찬가지입니다. apply()와 call() 중 어느 쪽을 쓸지는 순전히 개발자의 재량이며 매개변수를 전달하기 편리한 방식으로 택하면 됩니다. arguments 객체를 그대로 전달해도 되거나 매개변수로 전달할 데이터가 이미 배열 형태로 준비되어 있다면 apply()가 나을 것이고, 그렇지 않다면 call()이 더 나을 겁니다. 전달할 매개변수가 없다면 두 메서드는 완진히 똑같습니다.

물론 apply()와 call()의 진가는 매개변수를 전달해 호출하는 것이 아니라 this를 바꾸는데 있습니다. 다음 예제를 보십시오.

이 예제는 this 객체를 설명할 때 썼던 예제를 조금 고친 겁니다. 이번에도 sayColor()는 전역 함수로 정의되었으므로 전역 스코프에서 호출하면 this.color를 window.color로 평가하여 "red"를 표시합니다. sayColor.call(this)나 sayColor.call(window)와 같이 호출하면 함수 컨텍스트를 명시적으로 전역 스코프로 지정하는 것인데 이렇게 해도 마찬가지로 "red"를 표시합니다. 반면 sayColor.call(o)는 함수의 컨텍스트를 o로 설정하므로 "blue"를 표시합니다.

call()이나 apply()를 써서 스코프를 바꾸면 객체마다 일일히 메서드를 등록하지 않아도 된다는 장점이 있습니다. this 객체를 설명할 때는 o 객체에 직접 sayColor() 메서드를 등록했었지만 이번에는 그렇게 하지 않았습니다.

ECMAScript 5판의 함수에는 bind()라는 메서드도 정의되었습니다. 이 메서드는 새 함수 인스턴스를 만드는데 그 this는 bind()에 전달된 값입니다. 예를 들어 다음 코드를 보십시오.

이 예제에서는 sayColor()에서 bind()를 호출하면서 객체 o를 넘겨 objectSayColor()라는 함수를 생성했습니다. objectSayColor() 함수의 this는 o에 묶이므로 전역에서 함수르 호출하더라도 항상 "blue"를 표시합니다.

출처 - http://www.florakid.com/florakid_lib/sub/javascript/apply_call_method.html

arguments 객체는 함수에 전달된 인수에 해당하는 Array같은 객체입니다.

구문

arguments

설명

arguments 객체는 모든 함수 내에서 이용 가능한 지역 변수입니다. arguments 객체를 사용하여 함수 내에서 함수의 인수를 참조할 수 있습니다. 이 객체는 함수에 전달된 각 인수를 위한 항목(entry)을 포함합니다, 첫 번째 항목의 인덱스가 0에서 시작하는. 예를 들어, 함수에 인수 셋이 전달된 경우, 다음과 같이 참조할 수 있습니다:

arguments[0]
arguments[1]
arguments[2]

arguments는 설정될 수도 있습니다:

arguments[1] = 'new value';

arguments 객체는 Array가 아닙니다. Array와 비슷하지만 length 빼고는 어떤 Array 속성도 없습니다. 예를 들어, pop 메서드가 없습니다. 그러나 실제 Array로 변환될 수 있습니다:

var args = Array.prototype.slice.call(arguments);

arguments를 실제 Array로 변환하기 위해 Array.from() 메서드 또는 전개 연산자를 사용할 수도 있습니다:

var args = Array.from(arguments);
var args = [...arguments];

var args = (arguments.length === 1 ? [arguments[0]] : Array.apply(null, arguments));

당신이 형식상 받기로 선언된 것보다 많은 인수로 함수를 호출하는 경우 arguments 객체를 사용할 수 있습니다. 이 기법은 가변 인수가 전달될 수 있는 함수에 유용합니다. 함수에 전달된 인수의 수를 결정하기 위해 arguments.length를 쓰세요, 그 뒤에 arguments 객체를 사용하여 각 인수를 처리하세요. 함수 signature에 매개변수의 수를 결정하기 위해서는, Function.length 속성을 쓰세요.

속성

arguments.callee

현재 실행 중인 함수를 가리킵니다.

arguments.caller 

현재 실행 중인 함수를 호출한 함수를 가리킵니다.

arguments.length

함수에 전달된 인수의 수를 가리킵니다.

arguments[@@iterator]

arguments의 각 인덱스 값을 포함하는 새로운 Array Iterator 객체를 반환합니다.

예

여러 문자열을 연결하는 함수 정의하기

이 예는 여러 문자열을 연결하는 함수를 정의합니다. 함수의 유일한 형식 인수는 연결할 항목을 구분하는 문자를 지정하는 문자열입니다. 함수는 다음과 같이 정의됩니다:

function myConcat(separator) {
  var args = Array.prototype.slice.call(arguments, 1);
  return args.join(separator);
}

이 함수에 인수를 얼마든지 전달할 수 있으며 리스트 내 항목처럼 각 인수를 사용하여 리스트를 만듭니다.

// "red, orange, blue" 반환
myConcat(", ", "red", "orange", "blue");

// "elephant; giraffe; lion; cheetah" 반환
myConcat("; ", "elephant", "giraffe", "lion", "cheetah");

// "sage. basil. oregano. pepper. parsley" 반환
myConcat(". ", "sage", "basil", "oregano", "pepper", "parsley");

HTML 리스트를 만드는 함수 정의하기

이 예는 리스트 HTML을 포함하는 문자열을 만드는 함수를 정의합니다. 함수의 유일한 형식 인수는 리스트가 정렬되지 않은(bulluet(글 머리 기호)가 붙는) 경우 "u" 또는 정렬된(번호가 매겨진) 경우 "o"인 문자열입니다. 함수는 다음과 같이 정의됩니다:

function list(type) {
  var result = "<" + type + "l><li>";
  var args = Array.prototype.slice.call(arguments, 1);
  result += args.join("</li><li>");
  result += "</li></" + type + "l>"; // end list

  return result;
}

이 함수에 인수를 얼마든지 전달할 수 있고, 표시된 유형의 리스트에 항목으로 각 인수를 추가합니다. 예를 들면:

var listHTML = list("u", "One", "Two", "Three");

/* listHTML은:

"<ul><li>One</li><li>Two</li><li>Three</li></ul>"

*/

나머지, 기본 및 비구조화된 매개변수

arguments 객체는 나머지 매개변수, 기본 매개변수 또는 비구조화된 매개변수와 함께 사용될 수 있습니다.

function foo(...args) {
  return arguments;
}
foo(1, 2, 3); // { "0": 1, "1": 2, "2": 3 }

그러나, 비엄격 함수에서는 mapped arguments 객체는 함수가 어떤 나머지 매개변수, 기본 매개변수 또는 비구조화된 매개변수든 포함하지 않는 경우에만 제공됩니다. 예를 들어, 기본 매개변수를 사용하는 다음 함수에서는, 100 대신에 10이 반환됩니다:

function bar(a=1) {
  arguments[0] = 100;
  return a;
}
bar(10); // 10

이 예에서, 어떤 나머지 매개변수, 기본 매개변수 또는 비구조화된 매개변수가 없는 경우에는, 100이 반환됩니다:

function zoo(a) {
  arguments[0] = 100;
  return a;
}
zoo(10); // 100

출처 - https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Functions/arguments

Undo tablespace

- 사용자가 DML 을 수행할 경우 원본 데이터(undo data)들을 저장해 두는 특별한 Tablespace

- 사용자가 생성 가능하며 관리 할 수 있음

- Undo 라는 용어는 8i 버전까지 rollback 이라는 용어로 사용됨

1. Undo tablespace 의 특징

- Oracle Server Process 는 이 Tablespace 에 Undo segment 를 생성하고 기본적으로 각 사용자 별로 undo segment(ex: _SYSMU1$) 를 할당하여 관리하며 사용자는 관여할 수 없음

- Undo tablespace 는 Instance 당 여러 개가 동시에 존재 할 수 있지만 사용되는 것은 한번에 1개이다.

-> create undo tablespace undo01 datafile '/~~~~/undo01.dbf' size 10M 으로 만들어 줘도 파라미터에 적용 시키지 않으면 바뀌지 않음

- 관리 방법은 AUM(Automatic Undo Management) 과 MUM(Manual Undo Management) 이 있음 -> 9i 버전 부터는 AUM 방식을 권장

2. Undo Tablespace 의 사용 목적

- Transaction Rollback – 사용자가 rollback 이라는 명령어를 수행할 경우에 이곳에 저장된 undo data를 사용해서 rollback 을 수행함

- Read Consistency (읽기 일관성) –CR 작업을 통해 트랙잭션이 끝나지 않은 데이터는 변경 전 데이터를 보여줌.

- 다음 그림과 같이 update 가 발생하면 Datafile 에서 DB Buffer Cache 로 데이터 블록을 불러오게 되며 블록에는 lock 이 설정되어 아무도 내용을 볼 수 없는 상태

- 또한 원본 Data(Undo Data) 는 undo segment 에 저장되게 된다.

 - Update 가 수행되던 중 사용자 2에 의해서 select 가 수행되었을 때 undo segment 에서 DB Buffer Cache 로 원본 Data 를 복사하여 사용자 2에게 결과값을 보여주게 됩니다. 대신 1(홍길동) Data 는 lock 이 설정되어 commit 이나 rollback 이 수행되기 전까지는 1 block 에 다른 사용자가 접근할 수 없습니다.

- Transaction Recovery (Instance recovery) : 운영 중이던 DB 서버가 비정상적으로 종료 되었을 때 Roll Forward 와 Roll backward 작업을 수행해서 Dirty Database 를 Clean DB 로 만들어 주는 과정에 사용됨

- Undo Parameter 확인

- 신규 Undo Tablespace 생성

SQL>create undo tablespace undo01

2 datafile '/data/temp2/undo01.dbf' size 10M

3 autoextend on;

Tablespace created.

- Undo tablespace 를 생성 하여도 파라미터 파일을 변경 하여야 함.

SQL>alter system set undo_tablespace=undo01;

-PFILE 의 경우 파라미터 값을 직접 변경해야 나중에 다시 DB Open 시 문제가 발생하지 않는다.

- 각 세션 별로 사용중인 undo segment 확인

SQL>select s.sid,s.serial#,s.username,r.name "ROLLBACK SEG"

1 from v$session s,v$transaction t,v$rollname r

2 where s.taddr=t.addr

3 and t.xidusn = r.usn;

3. Undo segment 할당되는 원리

- Undo tablespace 는 Data file 의 크기가 증가만 되고 절대 줄어들지 않는다.

<하늘색 : 트랜잭션 완료, 갈색 : 트랜잭션 미완료>

다음과 같이 사용자가 DML(E) 을 수행하게 되면 가장 먼저 Server Process 는 Undo Segment 를 확보하게 되는데 이 때 기존에 만들어져 있던 Segment 중 트랜잭션이 완료된 것이 없는지를 확인한 후 그 곳에 덮어쓰게 됩니다.

- 다음과 같이 완료된 트랜잭션이 존재하지 않을 경우 새로운 undo segment 를 새로 생성하게 됩니다.

- 이런 식으로 더 이상 빈 공간이 존재하지 않을 경우 Data file 의 저장 공간이 허요하는 범위까지 늘어나다가 만약 더 이상 공간이 없게 되면 하나의 Segment 에 2개 세션 이상의 undo data를 함께 기록하게 됩니다. 이것조차 불가능하게 된다면 해당 트랜잭션은 에러를 발생 합니다.

- Undo tablespace 의 용량을 줄이기 위해서는 새로운 Undo Tablespace 를 생성후 파라미터 값을 변경시킨 다음 기존 Undo Tablespace 를 삭제 하셔야 합니다.

4. 주요 Parameter

- undo_retention àcommit 수행 후에도 해당 undo segment 내의 데이터를 다른 서버 프로세스가 덮어 쓰지 못하고 일정 시간동안 대기 시켜주는 파라미터이며 이 파라미터는 undo segment 의 여분이 존재할 경우에만 적용되며 항상 보장하지 않습니다.

- undo_retention_guarantee à undo_retention 파라미터는 여분이 존재하지 않을 경우 undo segment 가 재사용 되어지는데 반해 undo_retention_guarantee 파라미터는 설정된 시간동안 무조건 보장해줍니다.

- Oracle 10g 버전 부터는 ORA-01555:Snapshot too old 라는 에러를 줄이기 위해 undo retention 을 자동으로 관리하는 기능을 제공합니다.

- 다음은 undo tablespace 를 확인하고 guarantee 로 바꿔주는 명령어

SQL>alter tablespace undotbs retention noguarantee;

- no guarantee 로 변경하는 명령어

- NOT APPLY 는 Undo tablespace 가 아니므로 적용할 수 없습니다.

출처 - http://thankyeon.tistory.com/31

DML 문의 처리과정
==================

1. 해당 트랜잭션에 대해 언두 세그먼트를 할당한다.  이 경우 현재 온라인 상태인 언두 세그먼트 중
   하나를 우선적으로 사용한다. 언두 세그먼트의 선택은 랜덤하게 이루어지며, 다른 트랜잭션이 사용
   중이면 3번까지 재시도 한다.(undo segment는 block 단위로 owner ship을 갖는다.)
   이 과정에서 실패하면 오프라인 상태의 언두 세그먼트를 온라인화해서 사용한다.
   만인 이과정까지 실패하면, 새로운 언두 세그먼트를 생성한다.
   위 과정에서 언두 세그먼트를 할당받지 못하면 오라클 8i까지 사용하던 롤백 세그먼트
   알고리즘을 사용한다. 즉, 이미 다른 트랜젝션에 의해 사용 중인 언두 세그먼트 중 가장 사용량이
   적은 것을 사용한다. 서버 프로세스가 언두 세그먼트를 획득하는 시점에 적당한 온라인 상태의
   언두 세그먼트가 없으면 온라인 상태의 언두 세그먼트가 확보될 때까지 
   enq: US - contention 이벤트를 대기한다.
   
2. 언두 세그먼트를 할당받으면, 언두 세그먼트 헤더에 트랜잭션 테이블 슬롯(Transaction table slot)을
   생성한다.
   
3. 트랜젝션 테이블을 생성하고 나면 TXID(Transaction ID)를 생성하고, 현재 트랜잭션에 할당한다.
   TXID는 V$TRANSACTION 뷰의 XIDUSN, XIDSLOT, XIDSQN으로 표현되는데, 이 값은 트랜젝션에 할당된
   언두 영역의 언두 세그먼트 헤더에 존재하는 트랜잭션 테이블의 정확한 위치를 가리킨다. 트랜잭션은
   반드시 언두 영역을 할당받은 다음에 ID를 부여받은 것에 유의하자.
 
4. 트랜잭션의 대상이 되는 블록들을 버퍼 캐시로 적재하고 블록 헤더의 ITL(Interested Transaction List)에
   트랜잭션 엔트리(Transaction Entry)를 등록한다. 만일 ITL에 엔트리를 등록할 공간이 없다면, 공간이
   확보될 때까지 enq:TX - allocate ITL entry 이벤트를 대기한다.
   
5. 변경할 블록들의 변경 정보는 PGA에 체인지 벡터라는 이름으로 저장된다. 보통 하나의 로우가 변경되는 경우
   각각 언두 헤더 블록(체인지 벡터#1), 언두 블록(체인지 벡터#2), 데이터 블록(체인지 벡터#3)에 해당하는
   체인지 벡터들이 생긴다. 프로세스는 PGA의 체인지 벡터들을 리두 레코드(또는 리두 엔트리)라는 이름으로
   리두 버퍼(Redo Buffer)로 복사한다. 리두 버퍼에 변경 내용을 복사하는 과정에서 redo copy 래치, redo
   allocation 래치, redo writing 래치를 획득해야 한다. 이 과정에서 래치 경합이 발생하면 각각 
   latch: redo copy, latch: redo allocation, latch:redo writing 이벤트를 대기한다.
   
6. 이전 이미지(Before Image)에 대한 정보를 언두 블록에 기록하고, 데이터 블록을 변경한다. 변경된
   데이터 블록은 더티(Dirty) 상태가 된다. 또한 변경된 데이터 블록에 대한 CR 블록이 버퍼 캐시에 생성된다.
   만일 변경하고자 하는 로우가 현재 다른 트랜잭션에 의해 변경 중(즉 변경 후 아직 트랜잭션이 종료되지 않은
   상태)이라면 해당 트랜잭션이 종료되기를 기다려야 하며 enq: TX - row lock contention 이벤트를 대기한다.
   
7. 커밋이 수행되면, 트랜잭션에 SCN을 할당한다. 커밋 정보는 리두 버퍼에 저장된다.