DBMS_RANDOM package

The DBMS_RANDOM package will generate random data in character, numeric or alphanumeric formats. The size and the range from which to pickup the random values can also be specified. This package is created by the script dbmsrand.sql available in the <ORACLE_HOME>/rdbms/admin directory.

The following functions present in the package can be used to serve the purpose of generating random numbers and strings. RANDOM - generate random numbers.

VALUE - generate random numbers from the range provided. The range will be taken as 0-1 if none is provided.

STRING - generate strings in upper case, lower case or alphanumeric format.

• The first parameter takes the string type to be generated, the following values can be provided in upper or lower case.
• U - Upper case
• L - Lower case
• A - Alphanumeric
• X - Alphanumeric with upper case alphabets.
• P - Printable characters only.

  Providing any other character will return the output in upper case only.

  The size of the string should also be provided as the second parameter.

Oracle documentation says that it is necessary to initialize the package before using the random number generator. Oracle by default initializes the package with the seed value as the current user name, current time down to the second and the current session id.

INITIALIZE - Initialize the package to proceed with the number generation.

Provide a number (seed) as input to the routine.

SEED - Used to change the seed value. It is used in the internal algorithm to generate values. Setting this will

generate the random numbers in an order that will be similar in multiple sessions. Refer to the example below.

TERMINATE - Close the process of random number generation.

Examples:

Below are some examples of using the package.

E.g.: Generating a random number (positive or negative)

SQL> select dbms_random.random from dual;

       RANDOM
_____________
   1393936551

E.g.: Generating a random number between 0 and 1.

SQL> select dbms_random.value from dual;

        VALUE
_____________
            1

E.g.: Generating a random number from a range, between 1 to 1000.

SQL> select dbms_random.value(1,1000) num from dual;

          NUM
_____________
          611

E.g.: Generating a 12 digit random number.

SQL> select dbms_random.value(100000000000, 999999999999) num from dual;

          NUM
_____________
 175055628780

E.g.: Generating an upper case string of 20 characters

SQL> select dbms_random.string('U', 20) str from dual;

STR
_______________________
VUOQOSTLHCKIPIADIZTD

E.g.: Generating a lower case string of 20 characters

SQL> select dbms_random.string('L', 20) str from dual;

STR
____________________
xpoovuspmehvcptdtzcz

E.g.: Generating an alphanumeric string of 20 characters. There is a bug in Oracle 8i that results in special (non-alphanumeric) characters such as ']' in the string. This is resolved in Oracle 9i.

SQL> select dbms_random.string('A', 20) str from dual;

STR
__________________
sTjERojjL^OlTaIc]PLB

E.g.: Generating an upper case alphanumeric string of 20 characters

SQL> select dbms_random.string('X', 20) str from dual;

STR
________________________
SQ3E3B3NRBIP:GOGAKSC

E.g.: Generating a string of printable 20 characters. This will output a string of all characters that could possibly be printed.

SQL> select dbms_random.string('P', 20) str from dual;

STR
___________________
*Yw>IKzsj\uI8K[IQPag

E.g.: Example for calling the dbms_random package and setting the seed for generating the same set of random numbers in different sessions. Please note that the same random numbers are generated in different sessions. Though I have found this to work on most accounts, in some cases, the first number generated was different in different sessions and the remaining were same. I recommend not using this option in any of production code until it is properly document by Oracle.

jaJA>declare
  2     l_num    number;
  3  begin
  4    l_num := dbms_random.random;
  5    dbms_output.put_line(l_num);
  6    dbms_random.seed('amar testing 67890');
  7    l_num := dbms_random.random;
  8    dbms_output.put_line(l_num);
  9  end;
 10  /
483791552
478774329

PL/SQL procedure successfully completed.

1. ROLLUP : N+1  개를 그룹핑
2. CUBE    : 2의 N 제곱개를 그룹핑

-----------------------------------------------------------------------------------
1. GROUP BY ROLLUP(A, B, C)
   1-1. A, B, C
   1-2. A, B
   1-3. A
   1-4. 전체
   로 그룹핑을 한다.

* 아래 두개의 차이를 확인해보자.

WITH T_TABLE AS
(
 SELECT '0001' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '01' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '02' SUBITEM, 30 USE, 3000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALl
 SELECT '0002' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL
)
SELECT
    ITEM
  , SUBITEM
  , SUM(USE)
  , SUM(AMOUNT)
  FROM T_TABLE
 GROUP BY ROLLUP(ITEM, SUBITEM)
;

WITH T_TABLE AS
(
 SELECT '0001' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '01' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '02' SUBITEM, 30 USE, 3000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL
)
SELECT
    ITEM
  , SUBITEM
  , SUM(USE)
  , SUM(AMOUNT)
  FROM T_TABLE
 GROUP BY ROLLUP((ITEM, SUBITEM))
;

-----------------------------------------------------------------------------------

WITH T_TABLE AS
(
 SELECT '0001' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '01' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '02' SUBITEM, 30 USE, 3000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL
)
SELECT
    GROUPING_ID('AVG')
  , GROUPING_ID(ITEM)
  , ITEM
  , GROUPING_ID(SUBITEM)
  , SUBITEM
  , SUM(USE)
  , SUM(AMOUNT)
  FROM T_TABLE
 GROUP BY ROLLUP('AVG', ITEM, SUBITEM)
;

WITH T_TABLE AS
(
 SELECT '0001' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '01' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '02' SUBITEM, 30 USE, 3000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0001' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '01' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '02' SUBITEM, 20 USE, 2000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL UNION ALL
 SELECT '0002' ITEM, '03' SUBITEM, 10 USE, 1000 AMOUNT FROM DUAL
)
SELECT
    DECODE(
     ITEM, NULL, DECODE(
         GROUPING_ID('AVG'), 1, 'AVG', 'TOTAL'
        ), ITEM
    ) ITEM
  , DECODE(
     GROUPING_ID(ITEM), 1, '', DECODE(
              GROUPING_ID(SUBITEM), 1, 'SUBTOTAL', SUBITEM
             )
    ) SUBITEM
  , DECODE(
     GROUPING_ID('AVG'), 1, AVG(USE),
          SUM(USE)
    ) USE
  , DECODE(
     GROUPING_ID('AVG'), 1, AVG(AMOUNT),
          SUM(AMOUNT)
    ) AMOUNT
  FROM T_TABLE
 GROUP BY ROLLUP('AVG', ITEM, SUBITEM)
;

-----------------------------------------------------------------------------------

2. GROUP BY CUBE(A, B, C)
   2-1. A, B, C
   2-2. A, B
   2-3. B, C
   2-4, A, C
   2-5, A
   2-6. B
   2-7. C
   2-8. 전체
   로 그룹핑을 한다.

발췌 : http://cafe.naver.com/stocknjoy/38439

                                            -펀드 가입시 선택사항-

*적립식-  정액적릭식과 자유 적립식으로 분류되며 1년 이상 만기를 설정해야 한다.

정액적립식 - 매월 지정된 날짜에 일정 금액을 투자하는 방식

(원칙적으로는 부부환매 안되지만 펀드에 따라 부분환매가 되는것도 있으며 부분환매가 되도 추가매수가 안되는것과 되는것으로 분리됨^^좀 복잡하지만 펀드 가입시 숙지해둬야 한다 )

자유적립식 - 기간을 정하되 납입금액, 납입횟수에 제한이 없이 불입이 가능한것

(원칙적으로는 부부환매 안되지만 펀드에 따라 부분환매가 되는것도 있으며 부분환매가 되도 추가매수가 안되는것과 되는것으로 분리됨^^좀 복잡하지만 펀드 가입시숙지해둬야 한다. )

*임의식(자유적립식) -기간과금액에 상관없이 자유로운 투자를 하는 경우(부분환매 된다, 만기 설정없다)

정액적립,자유적립,임의식은 구분이 없다는 말의 있다~ 왜 그럴까?? ㅎㅎ

정액적립하다 돈없어서 돈 못넣고 나중에 넣으면 자유 적립 또는 임의식이 된다 .

임의식으로 하다가 정액적립식으로처럼 매월 지정된 날짜에 자동이체 하면  정액적립이된다.

단 부분환매와 만기설정의 차이가 있다.

*거치식 - 목돈을 장기간 예치하는 경우 (추가 매수가 안된다)

                                         - 클래스 분류 -

A클래스- 선취 수수료를 부과하는 펀드 (운용비는 가장 저렴하다)
C클래스- 선취,후취 수수료를 부과하지 않는 펀드 (운용비가 A보다 비싸다)
e클래스- C클래스와 똑같으나 인터넷 전용으로 운용비가 싸다.(운용비가 C보다 저렴하다)

A는 장기투자시 유리(보통 2년이상투자시) , C와 e는 단기투자시 유리할수 있음(보통1~2년)
그러나 펀드마다 운용비 설정이 다르기 때문에 위의 내용이 100%로 부합하지는 않으니..
자신의 생각하고 있는 투자기간을 고려하여 펀드 가입시 클래스 별로 따져 봐서 자신에게 가장 유리한 클래스의 펀드를 들어야 한다.

                                          -그 외에 눈여겨 봐야 할것들-

운용보고서- 처음 펀드시작한  자라면 어려워 보일수 있으나 실제로 마음만 먹으면 그리 어렵지 않으며 펀드에 대한 가장 정확한 정보가 여기에 다 들어 있으니 필독해야 한다.

환매수수료-환매수수료의 개념은 조금은 복잡하여 자세하게 기술된 자료를 링크 걸어 놀께요^^

http://blog.naver.com/mobsters?Redirect=Log&logNo=50001566942

환매 대금 지급: 환매시 몇일 종가로 반영되어 몇일날 지급 받는지 알아두자.

ex) 3시이전 : 2영업일 기준가로 4영업일 지급
     3시이후 : 3영업일 기준가로 4영업일 지급

펀드 마다 다를수 있으니 이것 역시 확인해야한다~^^

                                              -추가매수 관련-

추가 매수 방법:  전화 , 인터넷

ex)미래에셋 디스커버리를 추가매수 할 경우..3시 이전에 추가매수시.. 오늘 종가=내일 기준가로 매수됨.
오늘 추가매수하면  예수금으로 잡혀 있다가  내일 실제 투자된다.  내일  확인해 보면 ....

원래 있던 원금 + 추가매수한 금액이 합쳐져서 원금이 된것을 확인 할수 있다.

              국내는 오후 3시이전에 추가매수시 오늘 종가=내일기준가로 매수됨.
              해외는 오후 5시이전에 추가매수시 오늘 종가=내일기준가로 매수됨.
펀드와 증권사에 따라서 조금은 다른 경우가 있으니 자신의 가입한 증권사에 문의하는게 가장 정확하다.

                                   -필자가 알고 있는 잡다한...정보와 Q&A-

1.동양종금 수수료 관련 Tip..

동양종금에서 월 10만원이상의 금융상품을 정기정액납부시 모든 입.출입 수수료가 무료이다..

필자의 경우 신영마라톤을 정기접릭식으로 설정하여 모든 수수료를 무료로 서비스 받고 있다..

단 부분환매하면 수수료 혜택이 없어지니 유념하자~

알아보면 무료로 이용가능한 여러 방법들이 있으니 받을 수 있는 혜택은 꼭 챙기도록 하자 ~ ~

2.설정일이란?

펀드의 생일로 펀드가 생겨난 날짜이다 . 이날은 펀드의 기준가가 1000으로 재설정된다.
만약 설정일 전날  기준가가 2000원이고 10만주를 가지고 있었다면 재설정후에는  기준가가 1000으로 설정되는 되신 20만주를 가지게 된다.(어떤한 손해,이익이 일어나지 않는다)
설정일 당일은 수익률을 확인해 보면..수익률의 변동이 심하게 나서 놀라는 분들이 있는데 기준가 재설정하면서 잠시 오류가 난 것이니 걱정안해도 된다. 오후나 다음날 확인해 보면 여지 없이 제대로 설정된 것을

확인 할 수 있다.

3. 추가매수시 수익율이 많이 떨어졌다?

추가매수 후에 수익율이 떨어진것을 보고 놀라서 질문하시는 분들도 가끔있는데 걱정안해도 된다.
원금이 커지니 수익율이 떨어지는 것이 당연하다.

4.  추가매수 타이밍 , 펀드 시작 시기

안탁까운 일이지만 그걸 자신있게 말해줄 수 있는 사람은 세상에 아무도 없다...
또한 단기적인 수익률은 .. 연연하지 않는게 건강에 좋다^^

예를 들어 보겠다.

ex)펀드를 시작하여 11개월동안 수익률이 30%났다고 가정해 보자.. 얼마나 좋겠는가? 히히;
근데 12개월되는 달..한달 사이에 수익률이 -25%가 났다면???(충분히 번번히 일어나는 일이다)OTL..
이제껏 조금이나마  더 이익보려고 매일 주가 확인하여 추가매수하고 매일 안절부절하고..했는데 결국은 이모든게 헛고생이 된 것이다...
고로 .. 단기적인 주가와 추가매수에 너무 연연하지 않아도 된다. 
말은 이렇게 하지만.. 사실 필자는  궁금하여.. 하루에도 몇번씩 확인한다는...ㅎㅎ

원문 : http://polly97.wordpress.com/2007/06/13/java-theory-and-practice-jts-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EB%B3%B4%EC%95%88%EA%B3%BC-%ED%8D%BC%ED%8F%AC%EB%A8%BC%EC%8A%A4-%EA%B7%A0%ED%98%95%EB%A7%9E%EC%B6%94%EA%B8%B0/

2002 년 5 월 01 일
2003 년 1 월 21 일 수정

JTS 시리즈를 통해 Brian은 트랜잭션의 기초와 J2EE 컨테이너가 트랜잭션 서비스를 EJB 컴포넌트에 투명하게 할 수 있는지를 설명했다. 이번에는 트랜잭션 경계화와 고립화 관리에 필요한 J2EE 기능을 설명한다. 또한 그들을 효과적으로 사용할 수 있는 가이드라인도 제시한다.

Part 1 (”JTS 이해하기 - 트랜잭션에 대한 소개“)과 Part 2 (”JTS 이해하기 - 장막 뒤의 마법 “)에서 트랜잭션이 무엇인지를 정의했고 트랜잭션의 기본 속성, Java Transaction Service와 J2EE 콘테이너가 함께 작동하여 J2EE 컴포넌트를 지원하는 방법을 설명했다. 이제는 트랜잭션 경계화(demarcation)와 고립(isolation)에 대해 알아보자.

EJB 컴포넌트의 트랜잭션 경계화와 고립 속성을 정의하는 책임은 애플리케이션 어셈블러에 있다. 이들을 부적절하게 설정하면 퍼포먼스, 확장성, 애플리케이션의 내구성에 심각한 결과를 초래할 수 있다. 불행히도 이러한 속성들을 적절히 설정하는 데에 정해진 규칙 같은 것은 없다. 다만 병행성 위험과 퍼포먼스 위험 사이에서 균형을 찾도록 도와주는 가이드라인이 있을 뿐이다.

Part 1에서 다루었듯이 트랜잭션은 기본적으로 예외 처리(exception-handling) 매커니즘이다. 무엇인가 잘못되었다면 복구할 수 있도록 도와준다. 실제로 나쁜 상태가 되는 것은 거의 없기 때문에 비용과 시간 할애를 최소화 할 수 있다. 애플리케이션에서 트랜잭션을 사용하는 방법에 따라 애플리케이션 퍼포먼스와 확장성에 큰 영향을 미칠 수 있다.

트랜잭션 경계화

J2EE 콘테이너는 트랜잭션이 어디에서 시작하고 끝나는지를 정의하는 두 가지 매커니즘 (빈 관리(bean-managed) 트랜잭션과 콘테이너 관리(container-managed) 트랜잭션)을 제공한다. 빈 관리 트랜잭션의 경우 UserTransaction.begin()과 UserTransaction.commit()을 이용하여 빈(bean) 메소드에서 트랜잭션을 시작하고 끝낸다. 반면, 콘테이너 관리 트랜잭션의 경우 좀 더 많은 유연성을 제공한다. 어셈블리 디스크립터에 각 EJB 메소드를 위한 트랜잭션 속성을 정의함으로서 각 메소드 별로 트랜잭션 요구사항이 무엇인지를 지정할 수 있고 콘테이너가 트랜잭션을 언제 시작하고 끝내야 하는지를 결정하도록 할 수 있다. 두 경우 모두 트랜잭션을 설계하는 기본 가이드라인은 같다.

위로

전략

트랜잭션 경계화의 첫 번째 규칙은 “짧게 유지할것!” 트랜잭션은 병행 제어를 제공한다. 이것은 리소스 매니저가 트랜잭션 과정 중에 액세스한 데이터 아이템을 대신하여 lock을 얻어 트랜잭션이 끝날때까지 그들을 보유하고 있어야 한다는 것을 의미한다. 여러분이 lock을 보유하고 있는 동안에 다른 트랜잭션은 lock을 해제할 때까지 기다린다. 트랜잭션이 매우 길어지면 모든 다른 트랜잭션들은 저지당하고 애플리케이션 쓰루풋은 내려가기 마련이다.

Rule 1: 트랜잭션을 가능한 한 짧게 유지하라!

트랜잭션을 짧게 유지함으로서 애플리케이션의 확장성을 향상시킨다. 트랜잭션을 가능한 짧게 유지하는 최상의 방법은 트랜잭션의 중간에 불필요하게 시간을 허비하는 어떤 작업도 수행하지 않고 특별히 트랜잭션의 중간에 사용자 인풋을 기다리지 않는다.

트랜잭션을 시작하고 데이터베이스에서 데이터를 도출하여 데이터를 디스플레이하고 사용자에게 트랜잭션 동안 선택을 하도록 요청하고 싶을 것이다. 하지만 이렇게 하지 말기를 바란다. 사용자가 주의를 기울이더라도 응답하기 까지는 수 초가 걸리고 이는 데이터베이스에서 lock을 보유하기엔 긴 시간이다. 사용자가 점심을 먹거나 집에 가기위해 컴퓨터에서 물러나기라도 한다면 어떻게 될까? 애플리케이션은 간단히 멈추게 될 것이다. 트랜잭션 도중에 I/O를 수행하는 것은 재앙으로 가는 비결이다.

Rule 2: 트랜잭션 도중 사용자 인풋을 기다리지 말것!

위로

관련 오퍼레이션을 함께 그룹핑 할 것

각 트랜잭션은 중대한 오버헤드를 갖고있기 때문에 오퍼레이션 당 오버헤드를 최소화하기위해 단일 트랜잭션에서 가능한 많은 오퍼레이션을 수행하는 것이 최상의 방법이라고 생각할 수도 있다. 하지만 Rule 1에 따르면 긴 트랜잭션은 확장성에 나쁘다고 한다. 그렇다면 오퍼레이션당 오버헤드를 줄이는 것과 확장성 사이의 균형을 어떻게 맞추면 되는가?

Rule 1–트랜잭션 당 한 오퍼레이션–을 논리적 마지막 수단으로 취한다면 추가적인 오버헤드를 가져올 뿐 아니라 애플리케이션 상태의 일관성도 타협하게 된다. 트랜잭션 리소스 매니저는 애플리케이션 상태의 일관성을 관리하도록 되어있다. 하지만 그들은 일관성을 정의하기 위해 애플리케이션에 의존한다. 사실 트랜잭션을 설명할 때 우리가 사용하는 일관성의 정의는 다소 모호하다. 일관성은 애플리케이션이 말하는 모든것을 의미한다.

Part 1에서는 한 어카운트에서 다른 어카운트로 자금을 이동하는 뱅킹 애플리케이션 예제를 보았다. Listing 1은 SQL로 할 수 있는 구현을 보여준다. 다섯 개의 SQL 작동이 포함되어있다:
Listing 1. 자금 이체용 SQL 코드 샘플

SELECT accountBalance INTO aBalance

    FROM Accounts WHERE accountId=aId;

IF (aBalance >= transferAmount) THEN

    UPDATE Accounts

        SET accountBalance = accountBalance - transferAmount

        WHERE accountId = aId;

    UPDATE Accounts

        SET accountBalance = accountBalance + transferAmount

        WHERE accountId = bId;

    INSERT INTO AccountJournal (accountId, amount)

        VALUES (aId, -transferAmount);

    INSERT INTO AccountJournal (accountId, amount)

        VALUES (bId, transferAmount);

ELSE

    FAIL "Insufficient funds in account";

END IF

다섯 개의 개별 트랜잭션으로서 이 오퍼레이션을 실행한다면 어떤 일이 발생할까? 느려지는 것은 물론 일관성도 잃게된다. 예를들어 누군가가 첫 번째 SELECT 실행과 연속적인 차변 UPDATE 사이에 개별 트랜잭션으로 일부로서 A 어카운트에서 돈을 인출한다면 어떻게 될까? 이것은 이 코드에 의해 시행되어야 하는 비지니스 규칙을 위반한 것이 된다. 시스템이 첫 번째 UPDATE와 두번째 UPDATE 사이에서 고장난다면 어떻게 될까? 시스템이 복구되면 돈은 A 어카운트에 남아있게 되지만 B 어카운트에 기입되지 않게되고 이유는 기록되지 않는다. 이것은 두 계정의 소유자에게 안좋은 일이다.

Listing 1의 다섯 개의 SQL 오퍼레이션은 하나의 관련된 오퍼레이션으로 볼 수 있다. 즉 돈을 한 어카운트에서 다른 어카운트로 전송하는 것을 의미한다. 그러므로 우리는 모든것이 실행되거나 아예 실행되지 않거나 하기를 바라는 것이다. 그들이 단일 트랜잭션에서 모두 실행되어야 하는 이유가 바로 이것이다.

Rule 3: 관련 오퍼레이션을 단일 트랜잭션으로 그룹핑 할것!

위로

이상적인 균형

Rule 1은 트랜잭션이 되도록이면 짧아져야 할 것을 요구하고 있다. Listing 1의 예제에서는 일관성을 유지하기 위해서 가끔은 오퍼레이션들을 하나의 트랜잭션으로 묶어야 한다는 것을 보여주었다. 물론 이 모든 것은 어떤 구성요소들이 “관련 오퍼레이션”인지를 결정하는 애플리케이션에 의존한다. Rule 1과 3을 조합하여 트랜잭션의 범위를 설명하는 일반적인 가이드라인을 만들수 있다. 이것이 Rule 4 이다:

Rule 4: 관련 오퍼레이션을 단일 트랜잭션으로 그룹핑하라. 단, 연관성 없는 오퍼레이션은 개별 트랜잭션으로 놓을것!

위로

콘테이너 관리 트랜잭션

콘테이너 관리 트랜잭션을 사용할 때, 트랜잭션이 어디서 시작하여 어디에서 끝나는지를 명확히 설명하는 대신 각 EJB 메소드를 위한 트랜잭션 요구사항을 정의한다. 트랜잭션 모드는 빈의 assembly-descriptor의 container-transaction 섹션의 trans-attribute 엘리먼트에 정의되어 있다. 메소드의 트랜잭션 모드는 호출 메소드가 트랜잭션이 이미 포함되어 있는지의 여부를 나타내는 상태와 더불어 EJB 메소드가 호출 될 때 콘테이너가 어떤 액션을 취할지 결정한다:
Listing 2. EJB 어셈블리 디스크립터 샘플

<assembly-descriptor>

  ...

  <container-transaction>

    <method>

      <ejb-name>MyBean</ejb-name>

      <method-name>*</method-name>

    </method>

    <trans-attribute>Required</trans-attribute>

  </container-transaction>

  <container-transaction>

    <method>

      <ejb-name>MyBean</ejb-name>

      <method-name>logError</method-name>

    </method>

    <trans-attribute>RequiresNew</trans-attribute>

  </container-transaction>

  ...

</assembly-descriptor>

J2EE 스팩은 여섯 개의 트랜잭션 모드를 정의한다: Required, RequiresNew, Mandatory, Supports, NotSupported, Never. Table 1은 각 모드의 작동을 요약해 놓은 것이다. 기존 트랜잭션에 있을 때 호출될 때와 트랜잭션에 없을 때 호출 될 경우로 분류했다. 각 모드를 지원하는 EJB 컴포넌트 유형도 설명했다

Table 1. 트랜잭션 모드

콘테이너 관리 트랜잭션만을 사용하는 애플리케이션에서, 트랜잭션을 시작할 수 있는 유일한 방법은 트랜잭션 모드가 Required 또는 RequiresNew인 EJB 메소드를 컴포넌트가 호출할 경우이다. 콘테이너가 호출한 결과로서 트랜잭션을 만들 때, 그 트랜잭션은 메소드가 완료될 때 닫힌다. 메소드가 정상적으로 리턴되면 콘테이너는 트랜잭션을 발생시킨다. 예외를 주어 메소드가 종료하면 콘테이너는 트랜잭션을 롤백(roll back)하고 예외를 선언한다. 메소드가 기존 T 트랜잭션에 있을 때 호출되고 그 트랜잭션 모드는 메소드가 트랜잭션 없이 실행되거나 새로운 트랜잭션에서 실행되어야 한다는 것을 지정하면, T 트랜잭션은 메소드가 완료될 때 까지 중지하고 이전의 T 트랜잭션은 시작된다.

위로

트랜잭션 모드 선택하기

빈 메소드를 위해 어떤 모드를 선택해야 할까? 세션과 message-driven bean의 경우 모든 호출이 트랜잭션의 일부로서 실행될 것을 확인하기 위해 Required를 사용해야 하지만 메소드가 더 큰 트랜잭션의 컴포넌트가 되도록 할 수 있다. RequiresNew로 시도해보자. 이것은 메소드의 작동이 호출된 메소드의 행동과 개별적으로 이루어진다는 것을 확신할 때만 사용될 수 있다. RequiresNew는 전형적으로 시스템에서 다른 객체들과 관련이 없는 객체를 가지고 사용된다.

CMP (container-managed persistence) 엔터티 빈의 경우, Required를 사용해야 할 것이다. Mandatory 또한 합당한 옵션이 될 수 있는데 특별히 초기 개발에 맞다. CMP 엔터티빈에 RequiresNew 를 사용할 수는 없다. NotSupported와 Never는 비 트랜잭션 리소스용이다.

EJB 애플리케이션이 올바르게 디자인될 때 트랜잭션 모드에 대한 위 가이드라인은 Rule 4의 트랜잭션 경계화를 만들어낸다. J2EE 아키텍쳐는 애플리케이션을 가장 작은 프로세싱 청크로 분해되는 것을 장려한다.

위로

고립

Part 1에서, 고립(isolation)은 한 트랜잭션의 효과가 동시에 실행하고 있는 다른 트랜잭션에 보이지않는 것이라고 정의했다. 트랜잭션의 관점에서 트랜잭션은 병렬보다는 순차적으로 실행한다. 트랜잭션 리소스 매니저가 많은 트랜잭션들을 동시에 프로세스 하면서 “고립의 환상”을 제공한다. 가끔씩 고립의 제약조건은 새로운 트랜잭션 시작을 기존 트랜잭션이 완료될 때까지 미루도록 한다. 트랜잭션을 완료하는 것에는 적어도 하나의 동기식(synchronous)의 디스크 I/O가 포함되어있기 때문에 초당 트랜잭션의 수를 초당 디스크 쓰기의 수로 제한할 수 있다. 이것은 확장성에 좋지 않다.

실제로 고립 요구조건을 풀어서 더 많은 트랜잭션들이 동시에 실행될 수 있도록 하고 시스템 응답과 더 나은 확장성으로 향상시킬 수 있다. 거의 모든 데이터베이스는 네 개의 표준 고립 레벨을 지원한다: Read Uncommitted, Read Committed, Repeatable Read, Serializable.

콘테이너 관리 트랜잭션을 위한 고립 관리는 현재 J2EE 스팩의 범위를 벗어나있다. 하지만 IBM WebSphere와 BEA WebLogic 같은 많은 J2EE 콘테이너는 콘테이너 스팩의 확장을 제공하여 트랜잭션 모드가 어셈블리 디스크립터에 설정되는 것과 같은 방식으로 메소드 기반으로 트랜잭션 고립 레벨을 설정할 수 있다. 빈 관리 트랜잭션의 경우 JDBC 또는 다른 리소스 매니저 커넥션을 통해 고립 레벨을 설정할 수 있다.

고립 레벨 간 차이점을 보기위해 여러가지 병행성 위험을 분류해 보겠다. 다음 위험요소들 모두는 두 번째 트랜잭션이 이미 시작한 후에도 첫 번째 트랜잭션이 두 번째 트랜잭션에 보여진 결과와 연관되어있다:

네 개의 표준 고립 레벨은 이러한 세 개의 고립 위험과 관련되어있다. (Table 2). 가장 낮은 고립 레벨은 Read Uncommitted 로서 다른 트랜잭션에서 이루어진 변경을 막지 못한다. 하지만 읽기 lock에 대한 경쟁(contention)을 요구하지 않기 때문에 가장 빠르다. 가장 높은 고립 레벨인 Serializable은 위에 제사한 고립의 정의와 일치한다. 각 트랜잭션은 다른 트랜잭션의 효과로부터 완전히 고립된다.

Table 2. 트랜잭션 고립 레벨

대부분의 데이터베이스 경우 기본 고립 레벨은 Read Committed 인데 트랜잭션의 어떤 지점에서도 애플리케이션 데이터가 보이는 것을 방지해주기 때문에 유용하다. Read Committed는 가장 전형적인 짧은 트랜잭션에 사용하기 알맞은 고립 레벨이다.

높은 수준의 고립인 Repeatable Read와 Serializable은 트랜잭션 전체에서 높은 수준의 일관성이 필요할 때 알맞다. 데이터 일관성이 절대적으로 필요한 경우 새로운 열 생성을 방어할 필요가 있다. 이때 Serializable을 사용해야 한다.

가장 낮은 고립 레벨인 Read Uncommitted는 거의 쓰이지 않는다. 정확하지 않는 값을 얻고자 할 때 쓰이며 질의는 예기치 않은 퍼포먼스 오버헤드를 만들게 된다. 주문 수량 또는 당일 주문받은 달러 같이, 빠르게 수량을 계산할 때에는 Read Uncommitted가 전형적으로 사용된다.

고립과 확장성 사이에는 모순이 존재하기 때문에 트랜잭션에 고립 레벨을 선택할 때에는 특별한 주의를 기울여야 한다. 너무 낮은 레벨을 선택하면 데이터에 위험부담이 생긴다. 또, 너무 높은 레벨을 선택하면 퍼포먼스에 좋지 않다. 일반적으로 데이터 일관성 문제는 퍼포먼스 문제보다 더 심각하다:

Rule 5: 데이터를 안전하게 하는 가장 낮은 고립 레벨을 사용하되 불확실할 경우 Serializable을 사용할것!

컴포넌트를 개발 할 때 고립의 요구 사항에 대해 신중하게 생각해봐야 한다. 만약 퍼포먼스가 문제가 된다면 나중에 당황하지 않도록 낮은 고립 레벨도 견딜 수 있는 트랜잭션을 작성해야 한다. 어떤 메소드가 작동하고 고립 레벨을 정확히 설정하기 위한 일관성 전제조건이 무엇인지를 알 필요가 있으므로 개발하면서 일관성 요구사항과 전제조건을 세심하게 문서화 하는 것이 좋다.

위로

결론

이 글에 제시된 가이드라인들이 다소 모순처럼 보인다. 트랜잭션 경계화와 고립은 근본적으로 모순 그 자체이기 때문이다. 안전성과 툴의 퍼포먼스 오버헤드사이의 균형을 유지해야 한다.

위로

참고자료

• developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
• Part 1 (”JTS 이해하기 - 트랜잭션에 대한 소개“)과 Part 2 (”JTS 이해하기 - 장막 뒤의 마법 “).
• Transaction Processing: Concepts and Techniques : Jim Grey, Andreas Reuter.
• Principles of Transaction Processing : Philip Bernstein, Eric Newcomer.
• Mastering Enterprise JavaBeans :Ed Roman, Tyler Jewell, Scott Ambler.
• Transaction Management under J2EE 1.2 (JavaWorld, July 2000).
• “WebSphere Application Server Development Best Practices for Performance and Scalability” 백서.
• “Best practices to improve performance in JDBC” 튜토리얼.
• developerWorks Java technology zone.