JEUS Server 안내서 - TmaxSoft · 2019-04-09 · 3.2.2. Thread 제어..... 41 제4장 JEUS 클러스터링 ... 제8장 DB Connection Pool

JEUS

Server 안내서

JEUS v6.0 Fix#8

Copyright © 2011 TmaxSoft Co., Ltd. All Rights Reserved.

Copyright Notice

Copyright © 2011 TmaxSoft Co., Ltd. All Rights Reserved.

대한민국 경기도 성남시 분당구 서현동 272-6 우) 463-824

Restricted Rights Legend

All TmaxSoft Software (JEUS®) and documents are protected by copyright laws and the Protection Act of Com

puter Programs, and international convention. TmaxSoft software and documents are made available under the

terms of the TmaxSoft License Agreement and may only be used or copied in accordance with the terms of this

agreement. No part of this document may be transmitted, copied, deployed, or reproduced in any form or by any

means, electronic, mechanical, or optical, without the prior written consent of TmaxSoft Co., Ltd.

이 소프트웨어(JEUS®) 사용설명서의 내용과 프로그램은 저작권법, 컴퓨터프로그램보호법 및 국제 조약에 의해

서 보호받고 있습니다. 사용설명서의 내용과 여기에 설명된 프로그램은 TmaxSoft Co., Ltd.와의 사용권 계약 하에

서만 사용이 가능하며, 사용권 계약을 준수하는 경우에만 사용 또는 복제할 수 있습니다. 이 사용설명서의 전부 또

는 일부분을 TmaxSoft의 사전 서면 동의 없이 전자, 기계, 녹음 등의 수단을 사용하여 전송, 복제, 배포, 2차적 저

작물작성 등의 행위를 하여서는 안 됩니다.

Trademarks

JEUS® is registered trademark of TmaxSoft Co., Ltd. Other products, titles or services may be registered trademarks

of their respective companies.

JEUS®는 TmaxSoft Co., Ltd.의 등록 상표입니다. 기타 모든 제품들과 회사 이름은 각각 해당 소유주의 상표로서

참조용으로만 사용됩니다.

Open Source Software Notice

This product includes open source software developed and/or licensed by "OpenSSL", "RSA Data Security, Inc.",

"Apache Foundation", and "Jean-loup Gailly and Mark Adler". Information about the aforementioned and the related

open source software can be found in the "${INSTALL_PATH}/license/oss_licenses" directory.

본 제품은 “OpenSSL”, “RSA Data Security, Inc.”, “Apache Foundation” 및 “Jean-loup Gailly와 Mark Adler”에 의

해 개발 또는 라이선스된 오픈 소스 소프트웨어를 포함합니다. 관련 상세 정보는 제품의 디렉터리 “${IN

STALL_PATH}/license/oss_licenses”에 기재된 사항을 참고해 주십시오.

안내서 정보

안내서 제목: JEUS Server 안내서

발행일: 2011-11-04

소프트웨어 버전: JEUS v6.0 Fix #8

안내서 버전: v2.1.3

내용 목차

안내서에 대하여 .......................................................................................................................... xv

제1장 JEUS 구조 ........................................................................................................................ 1

1.1. 구성 요소 ..................................................................................................................... 1

1.2. 노드 ............................................................................................................................ 2

1.2.1. 가상 노드 .......................................................................................................... 2

1.2.2. 노드 클러스터링(Node Clustering) ...................................................................... 2

1.3. JEUS Manager ............................................................................................................ 3

1.3.1. 공통 서비스 ....................................................................................................... 4

1.3.2. JEUS Manager의 Life Cycle ............................................................................... 6

1.3.3. Base Port .......................................................................................................... 7

1.4. 엔진 컨테이너 .............................................................................................................. 7

1.4.1. 엔진(Engine) ..................................................................................................... 8

1.4.2. 주요 서비스 ....................................................................................................... 8

1.4.3. 엔진 컨테이너의 Life Cycle ................................................................................. 9

1.4.4. Invocation Manager ......................................................................................... 10

1.4.5. 디폴트 엔진 컨테이너 ....................................................................................... 10

1.4.6. JEUS Manager 감시 및 Self-Down 기능 ............................................................ 11

1.5. Class Loader의 구조 ................................................................................................... 14

1.5.1. Isolated Class Loader ...................................................................................... 14

1.5.2. Shared Class Loader ....................................................................................... 15

제2장 JEUS 설정 ...................................................................................................................... 17

2.1. 개요 ........................................................................................................................... 17

2.1.1. JEUS Manager의 설정 ..................................................................................... 17

2.1.2. 실행 스크립트에 Java –D 파라미터 추가 ........................................................... 19

2.2. 노드 설정 ................................................................................................................... 19

2.2.1. 기본 노드 설정 ................................................................................................. 20

2.2.2. 가상 노드 설정 ................................................................................................. 22

2.2.3. 노드 클러스터링 설정 ....................................................................................... 23

2.3. 엔진 컨테이너 설정 ..................................................................................................... 23

2.3.1. 기본 설정 ........................................................................................................ 23

2.3.2. Invocation Manager 설정 .................................................................................. 25

2.3.3. 데이터베이스 매핑 설정 ................................................................................... 26

2.3.4. Lifecycle Method Invocation 설정 ...................................................................... 27

2.3.5. 기타 엔진 컨테이너 설정 .................................................................................. 28

2.4. 엔진 설정 ................................................................................................................... 30

2.4.1. 엔진 종류 설정 ................................................................................................. 30

2.4.2. 웹 서버 엔진 설정 ............................................................................................ 32

2.5. JEUS 튜닝 고려사항 ................................................................................................... 32

제3장 JEUS 제어 및 모니터링 ................................................................................................... 33

JEUS iii

3.1. JEUS 제어 및 모니터링 ............................................................................................... 33

3.1.1. JEUS Manager 기동과 종료 ............................................................................. 33

3.1.2. 노드 제어 및 모니터링 ...................................................................................... 35

3.1.3. 엔진 컨테이너의 제어 및 모니터링 .................................................................... 37

3.1.4. 엔진 제어 및 모니터링 ...................................................................................... 38

3.2. Thread 모니터링 및 제어 ............................................................................................. 39

3.2.1. Thread 모니터링 .............................................................................................. 39

3.2.2. Thread 제어 .................................................................................................... 41

제4장 JEUS 클러스터링 ............................................................................................................ 45

4.1. 클러스터링 종류 ......................................................................................................... 45

4.2. 노드 클러스터링 ......................................................................................................... 46

4.2.1. 노드 클러스터링 형성 ....................................................................................... 47

4.2.2. 노드 클러스터링 상태 전이 ............................................................................... 48

4.2.3. 노드 클러스터링 동적 노드 추가 ....................................................................... 48

4.2.4. 백업 노드 ....................................................................................................... 50

4.3. 노드 클러스터링 설정 ................................................................................................. 50

4.3.1. 노드 클러스터링 설정 ....................................................................................... 50

4.3.2. 백업 노드 설정 ................................................................................................. 52

4.4. 노드 클러스터링 컨트롤 .............................................................................................. 53

제5장 Security 관리 .................................................................................................................. 55

5.1. 암호화된 패스워드 설정 방법 ...................................................................................... 55

5.2. 비밀 키 파일 관리 ....................................................................................................... 57

5.2.1. 파일의 생성과 관리 .......................................................................................... 57

5.2.2. 파일 보호 옵션과 JEUS 기동 방법 ..................................................................... 57

5.3. keystore/truststore 관리 .............................................................................................. 58

5.4. 계정 관리 방법 ........................................................................................................... 59

제6장 JNDI Naming Server ...................................................................................................... 63

6.1. 개요 ........................................................................................................................... 63

6.2. 기본 개념과 구조 ........................................................................................................ 63

6.2.1. 기본 개념 ........................................................................................................ 63

6.2.2. JNDI Naming Server 아키텍처 .......................................................................... 64

6.2.3. JNDI 클러스터링 ............................................................................................. 65

6.3. JNDI Naming Server 설정 ........................................................................................... 67

6.3.1. JNSServer 설정 ............................................................................................... 67

6.3.2. JNSLocal 설정 ................................................................................................. 68

6.4. 클러스터링 환경에서 JNDI .......................................................................................... 69

6.4.1. Binding 옵션 설정 ............................................................................................ 69

6.5. JNDI 프로그래밍 ........................................................................................................ 72

6.5.1. JEUS 환경설정 ................................................................................................ 73

6.5.2. InitialContext를 위한 프로퍼티 설정 .................................................................. 73

6.5.3. Context를 사용한 Named Object의 lookup ........................................................ 74

6.5.4. Named Object를 사용 ...................................................................................... 75

iv JEUS Server 안내서

6.5.5. Context 닫기 ................................................................................................... 75

6.5.6. Context 생성 ................................................................................................... 75

6.5.7. 원격으로 lookup 실행 ....................................................................................... 75

제7장 External Resource ......................................................................................................... 77

7.1. 리소스 종류 ................................................................................................................ 77

7.2. 리소스 설정 ................................................................................................................ 78

7.2.1. 데이터 소스의 설정 .......................................................................................... 79

7.2.2. 메일 소스의 설정 ............................................................................................. 79

7.2.3. URL 소스의 설정 ............................................................................................. 79

7.2.4. 외부 소스의 설정 ............................................................................................. 80

7.2.5. JAXR 소스의 설정 ........................................................................................... 81

제8장 DB Connection Pool과 JDBC ......................................................................................... 83

8.1. 개요 ........................................................................................................................... 83

8.2. JDBC Connection Pool ............................................................................................... 83

8.2.1. Connection Pooling .......................................................................................... 84

8.2.2. 데이터 소스 ..................................................................................................... 84

8.2.3. 클러스터 데이터 소스 및 장애복구 기능 ............................................................ 86

8.3. JDBC 데이터 소스 설정 .............................................................................................. 87

8.3.1. 데이터 소스 관리 ............................................................................................. 87

8.3.2. 기본 설정 ........................................................................................................ 88

8.3.3. Custom DB 속성 추가 ...................................................................................... 92

8.3.4. Connection Pool 설정 ....................................................................................... 93

8.3.5. 클러스터 데이터 소스 설정 ............................................................................. 102

8.4. DB Connection Pool의 제어 및 모니터링 ................................................................... 107

8.4.1. DB Connection Pool의 제어 ............................................................................ 107

8.4.2. DB Connection Pool의 모니터링 ..................................................................... 108

8.5. JEUS JDBC 프로그래밍 ............................................................................................ 112

8.5.1. 간단한 JDBC 프로그래밍 ............................................................................... 112

8.5.2. 트랜잭션 프로그래밍 규칙 .............................................................................. 112

8.5.3. JDBC 드라이버의 커넥션 인스턴스를 얻고 싶을 때 .......................................... 113

8.5.4. Standalone 클라이언트에서의 Connection Pool ............................................... 113

8.6. 글로벌 트랜잭션(XA)과 커넥션 공유 ........................................................................... 113

제9장 트랜잭션 매니저 ............................................................................................................ 115

9.1. 개요 ......................................................................................................................... 115

9.1.1. 애플리케이션 ................................................................................................. 116

9.1.2. JEUS 트랜잭션 매니저 ................................................................................... 117

9.1.3. 리소스 매니저 ................................................................................................ 118

9.2. 서버 트랜잭션 매니저 설정 ........................................................................................ 118

9.2.1. Worker Thread Pool 설정 ............................................................................... 119

9.2.2. 타임아웃 설정 ................................................................................................ 120

9.2.3. 트랜잭션 매니저 용량 설정 ............................................................................. 122

9.2.4. Root Coordinator와 Sub Coordinator 관련 설정 ............................................... 122

JEUS v

9.2.5. 트랜잭션 Join 설정 ......................................................................................... 123

9.3. 클라이언트 트랜잭션 매니저 설정 .............................................................................. 123

9.3.1. 트랜잭션 매니저 사용 유무 설정 ...................................................................... 123

9.3.2. 트랜잭션 매니저 타입 설정 ............................................................................. 124

9.3.3. 트랜잭션 매니저의 TCP Port 설정 ................................................................... 124

9.3.4. Worker Thread Pool 설정 ............................................................................... 124

9.3.5. 타임아웃 설정 ............................................................................................... 124

9.3.6. 트랜잭션 매니저 용량 설정 ............................................................................. 126

9.4. 트랜잭션 애플리케이션 작성 ...................................................................................... 126

9.4.1. 로컬 트랜잭션 ................................................................................................ 126

9.4.2. 클라이언트 관리 트랜잭션 .............................................................................. 128

9.4.3. Bean 관리 트랜잭션 ....................................................................................... 130

9.4.4. 컨테이너 관리 트랜잭션 ................................................................................. 133

9.4.5. 트랜잭션 매니저 사용하기 .............................................................................. 135

9.5. 트랜잭션의 복구 ....................................................................................................... 135

9.5.1. 트랜잭션 복구 과정 ........................................................................................ 136

9.5.2. 복구 관련 로그 파일 및 설정 ........................................................................... 137

9.5.3. 리소스 매니저 장애 ........................................................................................ 138

제10장 세션 서버 .................................................................................................................... 139

10.1. 개요 ....................................................................................................................... 139

10.2. 중앙 세션 서버 ........................................................................................................ 139

10.2.1. 중앙 세션 서버의 개념 .................................................................................. 139

10.2.2. 중앙 세션 서버의 설정 .................................................................................. 142

10.2.3. 중앙 세션 서버의 튜닝 .................................................................................. 147

10.2.4. JEUS 5에서 JEUS 6로 설정 변환 .................................................................. 148

10.3. 분산 세션 서버 ........................................................................................................ 150

10.3.1. 분산 세션 서버의 개념 .................................................................................. 151

10.3.2. 분산 세션 서버의 설정 ................................................................................. 157

10.3.3. JEUS 5에서 JEUS 6로 설정 변환 .................................................................. 164

제11장 Logging ..................................................................................................................... 169

11.1. 개요 ....................................................................................................................... 169

11.2. JEUS 로거 기본 구조 .............................................................................................. 178

11.2.1. 기본 로거 파일 위치 ..................................................................................... 170

11.2.2. 로그 포맷 .................................................................................................... 172

11.2.3. 로거 리스트 ................................................................................................. 173

11.2.4. 사용자 로거 ................................................................................................. 186

11.2.5. 로그 메시지 모듈 이름 .................................................................................. 176

11.3. JEUS Logging 설정 ................................................................................................. 178

11.3.1. 로거 설정 .................................................................................................... 178

11.3.2. 로그 파일 Rotation 설정 ................................................................................ 184

11.3.3. 표준 출력과 표준 에러를 로그 형식으로 출력 설정 .......................................... 186

11.3.4. 동적으로 Logging 레벨 설정 ......................................................................... 187

vi JEUS Server 안내서

11.3.5. 프로퍼티 설정 .............................................................................................. 187

Appendix A. JEUS에서 사용하는 Port .................................................................................... 189

A.1. 서버 Port ................................................................................................................. 189

Appendix B. JDBC Data Source 구성 예제 ............................................................................. 191

B.1. 개요 ....................................................................................................................... 191

B.2. Oracle Thin(Type 4) 구성 예제 ................................................................................... 191

B.2.1. Oracle Thin Connection Pool DataSource ....................................................... 191

B.2.2. Oracle Thin XA Data Source .......................................................................... 192

B.2.3. java.util.Properties 설정 예제 with Oracle ASO ................................................ 193

B.3. Oracle OCI (Type 2) 구성 예제 .................................................................................. 194

B.3.1. Oracle OCI Connection Pool DataSource ........................................................ 194

B.4. DB2 구성 예제 ......................................................................................................... 196

B.4.1. DB2 Type 4(JCC) Connection Pool DataSource ............................................... 196

B.4.2. DB2 Type 4(JCC) XA DataSource .................................................................. 197

B.4.3. DB2 Type 2(JCC) XA DataSource .................................................................. 198

B.5. Sybase 구성 예제 ..................................................................................................... 199

B.5.1. Sybase jConnect 5.x Connection Pool DataSource .......................................... 199

B.5.2. Sybase jConnect 6.x XA DataSource .............................................................. 200

B.6. MSSQL 구성 예제 .................................................................................................... 201

B.6.1. MSSQL 2005 Connection Pool DataSource ..................................................... 201

B.7. Informix 구성 예제 .................................................................................................... 202

B.7.1. Informix Connection Pool Datasource ............................................................. 202

B.8. Tibero 구성 예제 ...................................................................................................... 204

B.8.1. Tibero Connection Pool Datasource ................................................................ 204

B.9. MySQL 5.x 구성 예제 ............................................................................................... 204

B.9.1. MySQL Connector/J Connection Pool Datasource ........................................... 204

Appendix C. standard.property ............................................................................................. 205

C.1. 프로퍼티 레퍼런스 ................................................................................................... 205

용어해설 ................................................................................................................................... 207

색인 .......................................................................................................................................... 209

JEUS vii

그림 목차

[그림 1.1] JEUS의 구성 요소 ........................................................................................................ 1

[그림 1.2] 4개를 연결한 JEUS 클러스터링 .................................................................................... 3

[그림 1.3] JEUS Manager의 상태 전이도 ...................................................................................... 6

[그림 1.4] 엔진 컨테이너의 상태 전이도 ........................................................................................ 9

[그림 1.5] Manager 감시의 상태전이 .......................................................................................... 11

[그림 1.6] Isolated Class Loader 계층 구조 ................................................................................. 14

[그림 1.7] Shared Class Loader 계층 구조 .................................................................................. 15

[그림 2.1] JEUSMain.xml 위치 ................................................................................................... 17

[그림 2.2] JEUS 엔진들의 디렉터리 구조 .................................................................................... 30

[그림 4.1] 3개의 노드와 설정 파일(JEUSMain.xml)을 포함한 JEUS 클러스터링 ............................. 46

[그림 4.2] 노드 클러스터링 장애 ................................................................................................. 47

[그림 4.3] 클러스터링의 상태전이 .............................................................................................. 48

[그림 4.4] JEUS 클러스터에 새로운 JEUS 노드(D)의 동적 추가 ................................................... 49

[그림 6.1] JNSServer와 JNSLocal의 관계 ................................................................................... 64

[그림 6.2] 클러스터링 환경에서 JEUS JNDI 아키텍처 .................................................................. 66

[그림 6.3] Replicate Bind ........................................................................................................... 70

[그림 6.4] Cache Bind ............................................................................................................... 71

[그림 6.5] Local Bind ................................................................................................................. 72

[그림 8.1] JEUS의 Connection Pooling ....................................................................................... 84

[그림 8.2] RAC에서 클러스터 데이터 소스 Failover 기능 .............................................................. 87

[그림 9.1] Root Coordinator와 Sub Coordinator의 관계 예제 ...................................................... 117

[그림 9.2] 단순화한 트랜잭션 복구 과정 .................................................................................... 136

[그림 10.1] 세션 서버의 구조 .................................................................................................... 140

[그림 10.2] 분산 세션 서버를 이용한 세션 클러스터링 구조 ........................................................ 151

[그림 10.3] 분산 세션 서버 내부 구조 ........................................................................................ 152

[그림 10.4] 분산 세션 서버에 의한 fail-over 구조 ........................................................................ 154

[그림 10.5] 분산 세션 서버의 백업 선택 알고리즘 ...................................................................... 156

JEUS ix

표 목차

[표 C.1] 프로퍼티 레퍼런스 ...................................................................................................... 205

JEUS xi

예 목차

[예 2.1] JEUS Manager의 설정 : <<JEUSMain.xml>> .................................................................. 18

[예 2.2] 노드 설정 : <<JEUSMain.xml>> ..................................................................................... 19

[예 2.3] 기본 노드 설정 : <<JEUSMain.xml>> .............................................................................. 20

[예 2.4] 가상 노드 설정 : <<vhost.properties>> ............................................................................ 22

[예 2.5] 엔진 컨테이너 설정 : <<JEUSMain.xml>> ....................................................................... 23

[예 2.6] 엔진 컨테이너 기본 설정 : <<JEUSMain.xml>> ............................................................... 23

[예 2.7] Invocation Manager 설정 : <<JEUSMain.xml>> ............................................................... 25

[예 2.8] Database Mapping 설정 : <<JEUSMain.xml>> ................................................................ 26

[예 2.9] Lifecycle Method Invocation 설정 : <<JEUSMain.xml>> ................................................... 27

[예 2.10] <<LifeCycleTester.java>> ............................................................................................. 28

[예 2.11] 기타 엔진 컨테이너 설정 : <<JEUSMain.xml>> .............................................................. 29

[예 2.12] 엔진 종류 설정 : <<JEUSMain.xml>> ............................................................................ 30

[예 4.1] 노드 클러스터링의 설정 1 : <<JEUSMain.xml>> .............................................................. 51

[예 4.2] 노드 클러스터링의 설정 2 : << JEUSMain.xml>> ............................................................. 51

[예 4.3] 백업 노드 설정 1 : << JEUSMain.xml>> .......................................................................... 52

[예 4.4] 백업 노드 설정 2 : << JEUSMain.xml>> .......................................................................... 52

[예 5.1] 암호화된 문자열 패스워드 설정 : <<accounts.xml>> ........................................................ 55

[예 5.2] 암호화된 문자열 패스워드 설정 : <<JEUSMain.xml>> ..................................................... 56

[예 5.3] 암호화된 문자열 패스워드 설정 : <<WEBMain.xml>> ...................................................... 56

[예 5.4] <<accounts.xml>> ......................................................................................................... 59

[예 6.1] Naming server 설정 : <<JEUSMain.xml>> ...................................................................... 67

[예 6.2] Server-side JNSLocal 설정 : <<JEUSMain.xml>> ............................................................ 68

[예 7.1] 리소스 설정 : <<JEUSMain.xml>> .................................................................................. 78

[예 7.2] URL 소스의 설정 : <<JEUSMain.xml>> .......................................................................... 79

[예 7.3] JMS 소스 설정 : <<JEUSMain.xml> ................................................................................ 80

[예 7.4] JAXR 소스의 설정 : <<JEUSMain.xml> ........................................................................... 81

[예 8.1] JDBC 데이터 소스 설정 : <<JEUSMain.xml>> ................................................................. 88

[예 8.2] ds-accounts.properties .................................................................................................. 91

[예 8.3] Custom DB 속성 추가 : <<JEUSMain.xml>> ................................................................... 92

[예 8.4] Connection Pool 설정 : <<JEUSMain.xml>> .................................................................... 93

[예 8.5] <check-query> 설정 ...................................................................................................... 98

[예 8.6] <check-query-timeout> 설정 .......................................................................................... 98

[예 8.7] <non-validation-interval> 설정 ........................................................................................ 98

[예 8.8] check-query 실패시 Pool에 있는 커넥션에 대한 destroy 정책 설정 .................................... 99

[예 8.9] jeus.jdbc.connectionpool.JEUSConnectionChecker ......................................................... 99

[예 8.10] <dba-timeout> 설정 ................................................................................................... 101

[예 8.11] 클러스터 데이터 소스 설정 : <<JEUSMain.xml>> ........................................................ 102

[예 8.12] 자동으로 Failback 설정 : <<JEUSMain.xml>> .............................................................. 104

[예 8.13] jeus.jdbc.helper.DataSourceSelector .......................................................................... 105

[예 8.14] foo.bar.SampleDataSourceSelector ............................................................................ 106

JEUS xiii

[예 8.15] <<JEUSMain.xml>> ................................................................................................... 107

[예 9.1] <<JEUSMain.xml>> ..................................................................................................... 119

[예 9.2] Worker Thread Pool 설정 : <<JEUSMain.xml>> ............................................................. 119

[예 9.3] 타임아웃 설정 : <<JEUSMain.xml>> ............................................................................. 120

[예 9.4] 트랜잭션 매니저 용량 설정 : <<JEUSMain.xml>> .......................................................... 122

[예 9.5] <<Client.java>> ........................................................................................................... 126

[예 9.6] <<Client.java>> ........................................................................................................... 128

[예 9.7] <<ProductManagerEJB.java>> ..................................................................................... 130

[예 9.8] <<Client.java>> ........................................................................................................... 131

[예 9.9] <<ProductManagerEJB.java>> ..................................................................................... 131

[예 9.10] <<Client.java>> ......................................................................................................... 133

[예 9.11] <<ProductManagerEJB.java>> ................................................................................... 134

[예 9.12] <<JEUSMain.xml>> ................................................................................................... 137

[예 10.1] 중앙 세션 서버 기본 설정 : <<JEUSMain.xml>> ........................................................... 143

[예 10.2] 노드 클러스터링과 세션 클러스터링 설정 : <<JEUSMain.xml>> .................................... 146

[예 10.3] <<vhost.properties>> ................................................................................................. 147

[예 10.4] 노드 johan : <<JEUSMain.xml>> ................................................................................ 148

[예 10.5] 노드 johan1 : <<JEUSMain.xml>> .............................................................................. 148

[예 10.6] 각 노드들의 웹 컨테이너 공통 : <<WEBMain.xml>> ..................................................... 149

[예 10.7] 노드 johan과 johan1의 공통 : <<JEUSMain.xml>> ....................................................... 149

[예 10.8] 분산 세션 서버의 설정 : <<JEUSMain.xml>> ............................................................... 157

[예 10.9] 분산 세션 서버 기본 설정 : <<JEUSMain.xml>> ........................................................... 158

[예 10.10] 세부 분산 세션 서버 설정 : <<JEUSMain.xml>> ......................................................... 160

[예 10.11] <<JEUSMain.xml>> ................................................................................................. 164

[예 10.12] <<JEUSMain.xml>> ................................................................................................. 166

[예 11.1] 로그 메시지 출력 ....................................................................................................... 173

[예 11.2] 로거 설정 : <<JEUSMain.xml>> .................................................................................. 179

[예 11.3] 로그 파일 Rotation 설정 : <<JEUSMain.xml>> ............................................................. 184

[예 11.4] 표준 출력과 표준 에러를 JEUS 로그 형식으로 출력 : <<JEUSMain.xml>> ..................... 186

[예 B.1] <<JEUSMain.xml>> .................................................................................................... 191

[예 B.2] <<JEUSMain.xml>> .................................................................................................... 192

[예 B.3] <<JEUSMain.xml>> .................................................................................................... 193

[예 B.4] <<JEUSMain.xml>> .................................................................................................... 195

[예 B.5] <<JEUSMain.xml>> .................................................................................................... 196

[예 B.6] <<JEUSMain.xml>> .................................................................................................... 197

[예 B.7] <<JEUSMain.xml>> .................................................................................................... 198

[예 B.8] <<JEUSMain.xml>> .................................................................................................... 199

[예 B.9] <<JEUSMain.xml>> .................................................................................................... 200

[예 B.10] <<JEUSMain.xml>> .................................................................................................. 201

[예 B.11] <<JEUSMain.xml>> .................................................................................................. 202

[예 B.12] <<JEUSMain.xml>> .................................................................................................. 203

[예 B.13] <<JEUSMain.xml>> .................................................................................................. 204

xiv JEUS Server 안내서

안내서에 대하여

안내서의 대상

본 안내서는 JEUS의 구조 및 서비스에 대해서 전반적으로 다룬다. 따라서 JEUS에 대한 이해를 필요로

하는 대부분의 사람들을 대상으로 한다.

안내서의 전제 조건

본 안내서는 JEUS의 구조를 이해하기 위한 기본적인 내용과 JEUS가 제공하는 서비스들에 대해서 설명

한다. JEUS의 구조를 먼저 이해하지 않으면 JEUS를 설정하거나 제어하는데 어려움이 따른다. 그러나 모

든 내용을 포함하는데는 한계가 있으므로 구체적인 내용은 주제에 따라 별도의 안내서를 참고하길 권장

한다.

본 안내서의 초반부에 설명된 “제1장 JEUS 구조”는 JEUS를 이해하는데 가장 중요한 부분이라고 할 수 있

다. 이 후 장에서는 각 서비스 별로 필요한 내용 및 설정 방법을 다루게 되므로 필요할 때마다 참고한다.

본 안내서를 원활하게 이해하기 위해서는 다음과 같은 사항을 미리 알고 있어야 한다.

● JEUS 사용 환경 및 JEUS에 대한 전체적인 이해

JEUS 소개 참조

● JEUS 서버의 구동 방법

JEUS 설치 및 시작하기 참조

안내서의 제한 조건

JEUS를 이해하기 위해서는 Java EE에 대한 기본 지식이 필요하다. 예를 들어, JNDI, JMX, JCA 등에 대

한 문서를 보기 위해서는 이들 표준에 대한 배경 지식이 있어야 한다. 이런 경우에는 표준 문서나 관련 문

서를 먼저 읽어보길 바란다.

기본적으로 본 안내서에서는 Java EE에 관한 내용은 설명하지 않고 JEUS 관련 내용만 설명한다.

안내서에 대하여 xv

안내서 구성

본 안내서는 JEUS의 메인 설정 파일인 JEUSMain.xml의 계층 구조를 따라서 구성되었고, 실제 JEUS의

구조와 비슷하다. 다음과 같이 11개의 장과 3개의 Appendix로 구성되어 있다.

● “제1장 JEUS 구조”

JEUS의 구성 요소 및 구성 요소가 제공하는 서비스에 대해 설명한다.

● “제2장 JEUS 설정”

JEUS 구성 요소들의 설정 방법에 대해 설명한다.

● “제3장 JEUS 제어 및 모니터링”

Command Line에서 JEUS를 제어하고 모니터링하는 방법을 설명한다.

● “제4장 JEUS 클러스터링”

JEUS의 클러스터링의 구조 및 동작에 대해 설명한다.

● “제5장 Security 관리”

JEUS 서버의 사용과 관련된 보안 사항에 대해 설명한다.

● “제6장 JNDI Naming Server”

JEUS JNDI의 기본적인 사항과 애플리케이션 개발 방법에 대해 설명한다.

● “제7장 External Resource”

JEUS와 연동하여 사용이 가능한 외부 리소스에 대해 설명한다.

● “제8장 DB Connection Pool과 JDBC”

JEUS에서 제공하는 Connection Pool 및 부가 기능, 사용법에 대해 설명한다.

● “제9장 트랜잭션 매니저”

JEUS의 트랜잭션 매니저와 그 주변 요소들에 대해 설명한다.

● “제10장 세션 서버”

세션 서버에 대한 개념과 설정 방법에 대해 설명한다.

● “제11장 Logging”

JEUS의 Logging 시스템에 대해 설명한다.

● “Appendix A. JEUS에서 사용하는 Port”

JEUS에서 사용하는 Port를 정리한다.

● “Appendix B. JDBC Data Source 구성 예제”

주요 JDBC 드라이버에 대한 Connection Pool 설정 예제에 대해 설명한다.

● “Appendix C. standard.property”

프로퍼티에 대해 설명한다.

xvi JEUS Server 안내서

안내서 규약

의미표기

프로그램 소스 코드의 파일명<<AaBbCc123>>

Ctrl과 C를 동시에 누름<Ctrl>+C

GUI의 버튼 또는 메뉴 이름[Button]

강조진하게

다른 관련 안내서 또는 안내서 내의 다른 장 및 절 언급" "(따옴표)

화면 UI에서 입력 항목에 대한 설명'입력항목'

메일계정, 웹 사이트하이퍼링크

메뉴의 진행 순서>

하위 디렉터리 또는 파일 있음+----

하위 디렉터리 또는 파일 없음|----

참고 또는 주의사항참고

주의할 사항주의

그림 이름[그림 1.1]

표 이름[표 1.1]

Java 코드, XML 문서AaBbCc123

옵션 파라미터[ command argument ]

‘<’와 ‘>’ 사이의 내용이 실제 값으로 변경됨< xyz >

선택 사항. 예) A|B: A나 B 중 하나|

파라미터 등이 반복되어서 나옴…

안내서에 대하여 xvii

시스템 사용 환경

본 안내서는 모든 예제와 환경 구성을 Microsoft Windows™의 스타일에 준해서 작성되었다.

UNIX와 같은 다른 환경에서 작업하는 사람은 몇 가지 사항만 고려하면 무리없이 사용할 수 있다. 대표적

인 것이 디렉터리 구분자인데, Windows 스타일인 “\”를 UNIX 스타일인 “/”로 바꿔서 사용하면 무리가 없

다. 이외에 환경변수도 UNIX 스타일로 변경해서 사용하면 된다. 그러나 Java 표준을 고려해서 문서를 작

성했기 때문에, 대부분의 내용은 동일하게 적용된다.

관련 안내서

본 문서를 읽은 후에는 다음 문서를 읽어보기를 권장한다.

설명안내서

JEUS 웹 컨테이너의 관리에 대해 내용과 Java EE WAR Archive, 서

블릿/JSP의 관리 및 Deploy하는 방법에 대해 기술한 안내서이다.

JEUS Web Container 안내서

JEUS EJB 엔진과 EJB 모듈의 Deploy에 대해 기술한 안내서이다.JEUS EJB 안내서

JEUS 메시지 기반 시스템(JMS)에 대해 기술한 안내서이다.JEUS MQ 안내서

Java EE 클라이언트와 JEUS 사이의 상호 운용에 대해 기술한 안내

서이다.

JEUS Application Client 안내서

JEUS와 Legacy 시스템과의 연결을 위한 Connector에 대해 기술한

안내서이다.

JEUS JCA 안내서

JEUS에서 Security 시스템의 설정 및 운용 방법과 Security 관련 프

로그래밍에 대해 기술한 안내서이다.

JEUS Security 안내서

JMX를 사용하여 JEUS를 관리하기 위한 내용을 기술한 안내서이다.JEUS JMX 안내서

JEUS의 Scheduler 기능에 대해 기술한 안내서이다.JEUS Scheduler 안내서

JEUS의 웹 관리 툴인 WebAdmin을 사용한 JEUS 의 설정 및 제어,

모니터링, 클러스터링, 리소스 설정 및 관리에 대해 기술한 안내서이

다.

JEUS WebAdmin 안내서

JEUS에 대한 소개와 설치 및 시작 방법에 대해 기술한 안내서이다.JEUS 설치 및 시작하기

JEUS를 사용할 때 도움이 되는 Reference를 기술한 안내서이다.JEUS Reference Book

참고 자료

● JEUSMain.xml 설정에 대한 XML Reference

JEUS_HOME\docs\reference\schema\index.html

xviii JEUS Server 안내서

연락처

Korea

TmaxSoft Co., Ltd

272-6, Seohyeon-dong, Bundang-gu,

Seongnam-si, Gyeonggi-do, 463-721

South Korea

Tel: +82-31-8018-1000

Fax: +82-31-8018-1115

Email: [email protected]

Web (Korean): http://www.tmax.co.kr

기술지원: http://technet.tmaxsoft.com

USA

TmaxSoft, Inc.

560 Sylvan Avenue Englewood Cliffs, NJ 07632

U.S.A

Tel: +1-201-567-8266

Fax: +1-201-567-7339


Web (English): http://www.tmaxsoft.com

Japan

TmaxSoft Japan Co., Ltd.

5F Sanko Bldg, 3-12-16 Mita, Minato-Ku, Tokyo, 108-0073

Japan

Tel: +81-3-5765-2550

Fax: +81-3-5765-2567


Web (Japanese): http://www.tmaxsoft.co.jp

안내서에 대하여 xix

http://www.tmax.co.kr

http://technet.tmaxsoft.com

http://www.tmaxsoft.com

http://www.tmaxsoft.co.jp

China

TmaxSoft China Co., Ltd.

Beijing Silver Tower, RM 1508, 2# North Rd Dong San Huan,

Chaoyang District, Beijing, China, 100027

China

Tel: +86-10-6410-6145~8

Fax: +86-10-6410-6144


Web (Chinese): http://www.tmaxsoft.com.cn

xx JEUS Server 안내서

http://www.tmaxsoft.com.cn

제1장 JEUS 구조

본 장에서는 JEUS의 구성 요소 및 그 구성 요소가 제공하는 서비스에 대해서 설명한다.

1.1. 구성 요소JEUS는 노드, JEUS Manager, 엔진 컨테이너로 구성된다.

[그림 1.1] JEUS의 구성 요소

다음은 JEUS의 주요 구성 요소에 대한 설명이다. 각 구성 요소에 대한 자세한 설명은 각 상세 절의 내용

을 참고한다.

● 노드(Node)

노드는 논리적인 개념으로 JEUS의 물리적인 구성 요소들, JEUS Manager와 여러 개의 엔진 컨테이너

를 포괄하는 서버 인스턴스를 가리킨다.

● JEUS Manager

JEUS Manager는 노드에서 하나 밖에 없는 물리적인 구성 요소이고 기동할 때 시작점이 된다. 이것의

역할은 노드에 속한 여러 엔진 컨테이너를 관리하고 이들이 공통적으로 필요로 하는 서비스를 제공한

다. 또한 엔진 컨테이너에서 공통적으로 필요로 하는 서비스를 제공한다.

제1장 JEUS 구조 1

다음은 JEUS Manager의 주요 서비스이다.

– JNDI 서비스

– 보안(Security) 서비스

– Logging 서비스

– 외부 클라이언트가 필요로 하는 서비스

● 엔진 컨테이너(Engine Container)

엔진 컨테이너는 노드에서 하나 이상 존재할 수 있는 물리적인 구성 요소이며, 사용자가 Deploy하는 애

플리케이션을 관리하고 이러한 애플리케이션이 필요로 하는 서비스를 제공한다.

다음은 엔진 컨테이너의 주요 서비스이다.

– Http 세션 클러스터링 서비스

– 트랜잭션 서비스

– 데이터베이스 또는 엔터프라이즈 정보 시스템(EIS : Enterprise Information System) 연결 서비스

– 스케줄러 서비스 등의 다양한 서비스

1.2. 노드노드는 논리적인 개념으로 JEUS의 물리적인 구성 요소들, JEUS Manager와 여러 개의 엔진 컨테이너를

포괄하는 서버 인스턴스를 가리킨다. 노드는 본래 일반적으로 사용되는 개념이지만 JEUS에서는 JEUS

Manager와 여러 엔진 컨테이너의 집합체라고 할 수 있다. 대체로 노드를 서버 장비 별로 하나씩 실행시키

는 것이 일반적이지만 JEUS의 가상 노드 기능에 의해서 하나의 머신에서 여러 개의 노드를 실행시킬 수

도 있다.

클러스터링 환경에서는 노드가 기본 구성 단위이다.

1.2.1. 가상 노드

JEUS의 노드 이름은 기본적으로 JEUS Manager가 구동되는 머신의 네트워크 이름(hostname)이다. 하지

만 한 머신에 여러 개의 노드를 띄우고 싶은 경우에 가상 노드 기능을 사용하여 각 노드에 가상의 이름을

부여할 수 있다. 이 기능을 이용하면 한 머신에 여러 노드를 설정해 놓고 클러스터도 구성할 수 있다. 물론

여러 머신에 분산하는 경우만큼 큰 효과를 기대할 수는 없지만 개발 환경에서 가상적으로 클러스터를 구

성하는 데 유용하다. 이 경우에 각각의 JEUS Manager에 서로 다른 Base Port를 할당해야 한다.

가상 노드 설정에 관해 좀 더 자세한 내용은 “2.2.2. 가상 노드 설정”을 참고한다.

1.2.2. 노드 클러스터링(Node Clustering)

JEUS에서는 노드 간에 Fail-Over, 부하 분산을 위해서 서로 다른 노드들과 연결하여 클러스터를 구성할

수 있도록 하고 있다. 이러한 기능을 노드 클러스터링이라고 한다.

2 JEUS Server 안내서

다음은 4개의 노드를 연결한 클러스터를 보여준다.

[그림 1.2] 4개를 연결한 JEUS 클러스터링

각 노드는 고유의 IP 주소를 가지고 있는 전용 머신에서 운영되거나 JEUS의 가상 노드 기능을 이용하면

2개 이상의 노드를 하나의 머신에 설치해서 클러스터를 구성할 수 있다. 클러스터링된 노드들은 JEUS

Manager 간에 P2P(Peer-to-Peer)로 연결을 맺고 주기적으로 서로의 상태를 점검한다. 만약 노드 하나가

다운되었을 경우, 이에 대한 대책으로 관리자에게 경고 메일을 보내고 백업 노드를 띄운다거나, 다운된 노

드로 가는 요청을 다른 노드로 가도록 Fail-Over 처리를 한다.

또한 각각의 노드에 있는 리소스와 애플리케이션을 같은 클러스터에 있는 다른 노드에서 액세스가 가능

하다.

노드 클러스터링에 관한 보다 자세한 내용은 “제4장 JEUS 클러스터링”을 참고한다.

1.3. JEUS ManagerJEUS Manager는 노드에서 하나 밖에 없는 물리적인 구성 요소이고 기동할 때 시작점이 된다. 이것의 역

할은 노드에 속한 여러 엔진 컨테이너를 관리하고 이들이 공통적으로 필요로 하는 서비스를 제공한다.

기동 과정에서는 먼저 JEUS Manager가 실행된 다음, 자동으로 엔진 컨테이너들이 시작되거나 또는 관리

툴에 의해서 이들을 시작시킬 수 있다. 실제 운영중에 엔진 컨테이너가 종료되었을 경우에는 종료된 엔진

컨테이너를 다시 실행시켜준다.

또한 엔진 컨테이너에서 공통적으로 필요로 하는 서비스를 제공한다. 다음은 JEUS Manager의 주요 서비

스이다.

● JNDI 서비스


● 보안(Security) 서비스

● Logging 서비스

● 외부 클라이언트가 필요로 하는 서비스

예를 들어, 원격 Java 클라이언트가 Java EE의 JMX API를 통해서 엔진 컨테이너들의 모니터링 관련

정보를 얻고 싶은 경우 Management 서비스를 이용하면 된다. 이외에도 외부 클라이언트의 요청을 엔

진 컨테이너로 중개하는 역할을 하기도 한다.

클러스터링 환경에서는 클러스터링에 참여한 노드들의 JEUS Manager 간에 서로 상태 체크를 하기 때문

에 Fail-Over 기능에서 중요한 역할을 한다. 노드에 대한 제어는 일반적으로 JEUS Manager를 통해서 이

루어지며, 콘솔 툴 이나 WebAdmin을 통해서 JEUS Manager에 명령을 내릴 수 있다.

참고

콘솔 툴에 대한 자세한 사항은 "JEUS Reference Book"을 참고하고, WebAdmin에 대한 사항은 "JEUS

WebAdmin 안내서"를 참고한다.

1.3.1. 공통 서비스

다음은 JEUS Manager에서 제공하는 엔진 컨테이너에서 공통적으로 필요로 하는 서비스에 대한 설명이

다.

● JNDI 서비스

JNDI 서비스는 Java EE에서 정의한 JNDI 표준의 매커니즘을 제공하는 것으로서, JEUS에 등록된 다양

한 객체들을 정해진 이름으로 찾아서 사용할 수 있는 방법을 제공한다. JEUS Manager에서는 이 서비

스를 제공하는 개체를 JNDI Naming 서버라고 부른다. 클러스터링 환경에서는 각각의 JEUS Manager

에서 동작하는 JNDI Naming 서버끼리 서로 정보를 교환하면서 마치 하나의 JNDI Naming 서버가 있는

것처럼 동작한다.

JNDI 서비스에 관한 자세한 내용은 “제6장 JNDI Naming Server”를 참고한다.

● 보안(Security) 서비스

보안 서비스는 애플리케이션 및 내부 컴포넌트의 보안 요청에 대한 응답 및 각종 인증 작업을 수행한다.

보안 서비스에 관련된 자세한 내용은 "JEUS Security 안내서"를 참고한다.


JEUS Manager 및 엔진 컨테이너에서 발생하는 이벤트와 에러를 파일로 기록한다. JEUS에서는 ja

va.util.logging API를 지원하므로 로그 레벨, 로그 핸들러 등을 설정할 수 있다. Logging 서비스에 관한

자세한 내용은 “제11장 Logging”을 참고한다.

● Management 서비스

Management 서비스는 Java Management Extensions (JMX)를 통해 서비스, 컴포넌트, 애플리케이션

에 대한 관리 및 모니터링을 위한 기반 서비스이다. JMX에 기술된 JMX Remote API 커넥터(RMI 커넥

터/JMXMP 커넥터), HTML 어댑터, SNMP 어댑터와 같은 관리 객체를 JEUS Manager에 설정하고, 이

를 통해 JEUS의 관리 및 모니터링 정보에 접속하는 방법을 제공한다.


Management 서비스의 설정 및 각 관리 객체에 대한 자세한 내용은 "JEUS JMX 안내서"를 참고한다.

● Http 세션 클러스터링 서비스

Http 세션 클러스터링 서비스는 서블릿 엔진들 사이에 Http 세션이 유지될 수 있도록 하는 서비스이다.

JEUS는 설정에 따라서 중앙식과 분산식 방식의 Http 세션 클러스터링을 지원한다. JEUS Manager에서

는 중앙식 Http 세션 클러스터링 서비스를 제공한다. 중앙식 Http 세션 클러스터링 서비스를 제공하는

JEUS Manager에 연결된 서블릿 엔진들은 Http 세션을 공유할 수 있다. 이 경우 서블릿 엔진에 대한 장

애에도 Http 세션은 유지된다.

JEUS Manager에서 제공되는 중앙식 Http 세션 클러스터링 서비스는 사용 및 관리의 장점이 있지만, 연

결된 모든 서블릿 엔진의 Http 세션의 백업 정보를 가지고 있기 때문에 JEUS Manager가 실행되는 JVM

에 많은 메모리 공간이 필요할 수 있다. 경우에 따라서 OutOfMemoryError가 발생할 수도 있다. 서버 운

영 시에 Http 세션에 대한 메모리 부담으로 OutOfMemoryError가 자주 발생한다면 분산식 Http 세션 클

러스터링 서비스를 사용하길 권장한다.

JEUS에서 제공하는 Http 세션 클러스터링 서비스에 관한 자세한 설명은 “제10장 세션 서버”를 참고한

다.

● 스케줄러 서비스

스케줄러는 사용자가 미리 지정한 시간에 특정 작업들을 실행시킨다. 스케줄러는 JEUSManager 레벨

뿐만 아니라 엔진 컨테이너 단위에서도 실행이 가능하다. 보다 자세한 정보는 "JEUS Scheduler 안내

서"를 참고한다.

● Class FTP 서비스

EJB 2.x의 경우 원격 클라이언트에서 EJB를 호출하기 위해서는 기본적으로 RMI Stub 클래스를 필요로

하게 된다. 이때 원격 클라이언트에 RMI Stub 클래스를 미리 패키징하지 않더라도 Class FTP 서비스를

통해서 필요한 클래스들을 전송받아서 사용할 수 있다.

만약 Class FTP 서비스를 사용하지 않는다면 RMI Stub 클래스들을 원격 클라이언트의 클래스 패스

(classpath)에 있어야 한다. 이에 대한 예제는 “JEUS EJB 안내서”의 “제11장 EJB 클라이언트”를 참고한

다.

참고

실제로 클래스 파일을 전송하는 프로토콜은 FTP 프로토콜이 아니라 HTTP 프로토콜을 사용한다.

● WebAdmin 서비스

WebAdmin은 JEUS를 관리하기 위한 웹 기반의 관리 콘솔이다. 사용자들은 WebAdmin을 통해서 좀 더

편리하게 애플리케이션 Deploy, 서버 설정 변경 등을 할 수 있다. 자세한 내용은 "JEUS WebAdmin 안

내서"를 참고한다.

● 외부 리소스(External Resources)

JEUS Manager는 애플리케이션에 여러 가지 종류의 외부 리소스에 대한 연결을 제공한다.

설명외부 리소스

데이터베이스와의 연결(JDBC 표준에서 정의한 데이터 소스)Data Source


설명외부 리소스

메일 서버와의 연결Mail Source

URL 소스와의 연결URL Source

TP Monitor(Tmax), IBM MQ 등의 엔터프라이즈 정보 시스템(EIS)과의 연결

(JCA 리소스 어댑터를 Deploy하는 방식과는 구분된다)

External Source

XML 레지스트리 소스JAXR Source

외부 리소스에 대한 연결 정보는 사용자가 직접 추가할 수 있으며 JNDI Naming 서버에 등록되어 애플

리케이션에서 JNDI lookup Operation을 통해 이용할 수 있다. 외부 리소스는 노드나 JEUS Manager에

속한다고 볼 수 없지만, JNDI Naming 서버에 등록되어 애플리케이션이나 JEUS의 각종 서비스들이 이

용하게 되므로 일종의 JEUS Manager 서비스로 분류한 것이다.

클러스터링 환경일 경우에는 JNDI Naming 서버를 통해서 모든 노드가 같은 리소스 정보를 공유해서

사용하게 된다. 리소스 설정에 관련된 내용은 “제7장 External Resource”를 참고한다.

1.3.2. JEUS Manager의 Life Cycle

JEUS Manager는 다음과 같은 동작 상태를 갖는다.

[그림 1.3] JEUS Manager의 상태 전이도

SHUTDOWN BOOTING

READYSHUTTINGDOWN

설명상태

JEUS Manager가 시작중인 상태로 아직 관리 툴로부터 명령을 받을 수 있는

단계는 아니다.

BOOTING

JEUS Manager의 기동이 완료되어 엔진 컨테이너를 시작하거나 JNDI 서비

스 등의 공통 서비스를 사용할 수 있는 상태이다.

READY

JEUS Manager가 중단되고 있는 상태로 엔진 컨테이너를 중단시키고 각종

서비스를 내리는 상태이다.

SHUTTINGDOWN

JEUS Manager가 실행되지 않은 상태이다.SHUTDOWN

JEUS Manager를 시작시키려면 실행 스크립트를 사용해야 한다. JEUS에서는 jeus라는 이름으로 제공한

다. jeus 스크립트를 실행하면 SHUTDOWN 상태에서 BOOTING 상태로 가게 되고, JEUS Manager의 초


기화가 완료되면 READY 상태가 된다. JEUS Manager가 READY 상태일 때 관리 툴로 엔진 컨테이너를

실행시키거나 JEUS Manager를 종료할 수 있다.

참고

jeus 스크립트의 사용 방법에 관해서는“JEUS Reference Book”의 “제3장 jeus”를 참고한다.

1.3.3. Base Port

JEUS가 시스템 내부, 다른 노드 또는 원격 클라이언트와 통신하기 위해 필요로 하는 기본 TCP 소켓 포트

를 Base Port라 한다. 기본적으로 9736을 사용한다. 이 Port는 JEUS Manager가 구동되면서 열리며 다른

서비스들의 Port는 이 Base Port에 기반하여 상대적으로 결정된다. 몇몇 서비스의 경우에는 서비스 특성

에 따라 별도의 Port를 사용하는 경우도 있지만 대부분의 서비스들은 Base Port를 통해 이용할 수 있다.

1.4. 엔진 컨테이너엔진 컨테이너는 실제 애플리케이션을 서비스하는 엔진들과 여러 공통 서비스들을 호스팅하는 서버 개체

를 의미한다.

엔진 컨테이너는 노드에서 하나 이상 존재할 수 있는 물리적인 구성 요소이며, 사용자가 Deploy하는 애플

리케이션을 관리하고 이러한 애플리케이션이 필요로 하는 서비스를 제공한다. 서블릿, EJB 컴포넌트를

관리하는 엔진(Engine)과 Java Message Service(JMS)를 제공하는 엔진이 있고, 이러한 엔진들이 필요로

하는 다음과 같은 서비스를 제공한다.


● 트랜잭션 서비스

● 데이터베이스(Database) 또는 엔터프라이즈 정보 시스템(Enterprise Information System) 연결 서비스

● 스케줄러 서비스 등의 다양한 서비스

엔진 컨테이너는 사용자가 구현한 애플리케이션이 Deploy되는 기본 Target이다. 하나의 애플리케이션을

노드에 Deploy할 경우, 실제로는 여러 개의 엔진 컨테이너에 각각 Deploy하게 된다. 물론 설정에 따라 특

정 엔진 컨테이너에만 Deploy할 수도 있다.

참고

JEUS Manager와 엔진 컨테이너를 물리적인 구성 요소라고 하는 이유는 각각 다른 JVM으로 실행되

기 때문이다. 이것은 일반적으로 하나의 JVM으로 서버 인스턴스를 구성하는 타 벤더의 제품들과 구

분되는 특징이다. 그러나 JEUS Manager와 엔진 컨테이너가 서로 다른 JVM이라고 하더라도 JEUS

Manager가 다운되었을 경우에는 노드가 다운된 것과 다름없기 때문에 그에 속한 모든 엔진 컨테이

너를 종료시킨다. 좀 더 자세한 내용은 “1.4.6. JEUS Manager 감시 및 Self-Down 기능”을 참고한다.


1.4.1. 엔진(Engine)

엔진은 Java EE에서 정의한 EJB 컨테이너, 웹 컨테이너와 매핑되는 개념으로 사용자가 Deploy한 컴포넌

트를 관리하는 역할을 한다. 엔진은 엔진 컨테이너에 포함되는 요소이며, JEUS Manager 및 엔진 컨테이

너가 제공하는 서비스들을 이용하여 컴포넌트를 실행시킨다.

JEUS의 엔진은 다음과 같이 4가지 종류가 있다.

설명엔진

EJB 컴포넌트를 관리하고 실행하는 EJB 컨테이너 역할을 한다. 이에

대한 자세한 사항은 "JEUS EJB 안내서"를 참고한다.

EJB 엔진

웹 컨테이너라고 할 수 있으며, 웹 클라이언트 또는 웹 서버로부터 요청

을 받아서 사용자가 Deploy한 서블릿(또는 JSP, JSF)을 통해 동적인 웹

서블릿 엔진(또는 웹 엔진)

콘텐츠를 생성한다. 이에 대한 자세한 사항은 "JEUS Web Container 안

내서"를 참고한다.

Java Message Service(JMS)를 제공한다. 이에 대한 자세한 사항은

"JEUS MQ 안내서"를 참고한다.

JMS 엔진

JEUS에서 제공하는 내장 웹 서버를 시작 또는 정지시키기 위해 사용하

는 Agent 역할을 한다.

웹 서버 엔진

참고로 내장 웹 서버는 WebtoB Standard Version에서 일부 기능이 제

외되어 있는 버전이다. 이에 대한 자세한 사항은 "JEUS Web Container

안내서"를 참고한다.

참고

엔진은 종류별로 최대 하나씩 엔진 컨테이너에 설정할 수 있다. 엔진은 JEUS Manager나 엔진 컨테

이너처럼 독립된 JVM으로 동작하는 물리적인 요소가 아니라 엔진 컨테이너에 속한 것이다. 그렇다

고 하나의 특정한 스레드로 볼 수 없으며, 기능적인 측면에서 나눈 개념이다.

1.4.2. 주요 서비스

다음은 엔진 컨테이너의 주요 서비스에 대한 설명이다.


서블릿에서 사용하는 Http 세션 객체를 여러 컨테이너에서 공유해서 사용할 수 있도록 하는 서비스이

다.

JEUS는 Http 세션 클러스터링 서비스를 제공한다. 설정에 따라서 중앙식과 분산식 Http 세션 클러스터

링을 제공한다. 엔진 컨테이너에서는 분산식 Http 세션 클러스터링 서비스를 선택적으로 제공할 수 있

다.

분산식 Http 세션 클러스터링 서비스를 선택하면 엔진 컨테이너들은 자신이 사용한 Http 세션를 가지고

있고, 해당 컨테이너에 없는 Http 세션의 요청에 대해서는 다른 컨테이너에서 가져와서 사용한다. 그리


고 각 컨테이너는 다른 컨테이너에 Http 세션 정보에 대한 백업본을 가지고 있기 때문에 컨테이너의 장

애 시에도 해당 컨테이너의 Http 세션은 유지된다.

분산식 Http 세션 클러스터링 서비스에 관한 자세한 설명은 “제10장 세션 서버”를 참고한다.

● 트랜잭션 서비스

트랜잭션 매니저를 통해서 Deploy된 애플리케이션이 트랜잭션을 사용할 수 있다. 트랜잭션 매니저에

관한 설명은 “제9장 트랜잭션 매니저”를 참고한다.

● 데이터베이스 연결 서비스

애플리케이션이 JDBC Connection Pool을 통해서 데이터베이스에 접근할 수 있다. 이에 관한 자세한

내용은 “제8장 DB Connection Pool과 JDBC”를 참고한다.

● 엔터프라이즈 정보 시스템(EIS) 연결 서비스

애플리케이션이 Deploy된 JCA 리소스 어댑터나 외부 리소스 등록 정보를 통해서 EIS에 접근할 수 있

다. JCA 리소스 어댑터에 관한 자세한 내용은 "JEUS JCA 안내서"를 참고한다.

● 스케줄러 서비스

스케줄러는 사용자가 미리 지정한 시간에 특정 작업들을 실행시켜준다. 스케줄러는 엔진 컨테이너 뿐

만 아니라 JEUS Manager 레벨에서도 실행이 가능하다. 보다 자세한 정보는 "JEUS Scheduler 안내서"를

참고한다.

● Management 서비스

Management 서비스는 JEUS Manager 뿐만 아니라 엔진 컨테이너에서도 독자적으로 제공한다. Man

agement 서비스의 설정 및 각 관리 객체에 대한 자세한 내용은 "JEUS JMX 안내서"를 참고한다.


기본적으로 Logging은 JEUS Manager가 담당하지만 엔진 컨테이너 독자적으로도 자신의 이벤트와 에

러를 파일로 기록할 수 있다. java.util.logging API를 지원하므로 로그 레벨, 로그 핸들러 등을 설정할 수

있다. Logging 서비스에 관한 자세한 내용은 “제11장 Logging”을 참고한다.

1.4.3. 엔진 컨테이너의 Life Cycle

엔진 컨테이너는 다음과 같은 동작 상태를 갖는다. 단, 엔진 컨테이너의 상태는 JEUS Manager에 의해서

결정된다.

[그림 1.4] 엔진 컨테이너의 상태 전이도

SHUTDOWN STARTING

READYSTOPPING


설명상태

JEUS Manager에 의해서 시작 중인 상태이다(서비스가 올라가거나 애플리

케이션이 Deploy 중인 상태이다).

BOOTING

서비스 초기화 및 애플리케이션 Deploy가 완료되어 외부의 요청을 처리할 수

있는 상태이다.

READY

JEUS Manager에 의해서 중단되고 있는 상태로 외부의 요청을 차단하고 각

종 서비스를 내리는 상태이다.

SHUTTINGDOWN

엔진 컨테이너가 실행되지 않은 상태이다.SHUTDOWN

JEUS Manager가 READY 상태일 때 관리 툴을 통해서 엔진 컨테이너를 시작시키거나 다운시킬 수 있다.

만약 엔진 컨테이너가 STARTING 상태에서 설정 오류나 시스템 오류로 인해 시작이 실패했을 경우에는

SHUTDOWN 상태가 된다. 이때 관리 툴에 의해서 다시 STARTING 상태로 될 수 있다. JEUS에서는 관리

툴로 콘솔 툴(jeusadmin), WebAdmin을 제공한다.

참고

콘솔 툴과 관련된 내용은 “JEUS Reference Book”의 “4.2.3. 공통 명령어”를, WebAdmin에 관한 자세

한 사항은 "JEUS WebAdmin 안내서"를 참고한다.

1.4.4. Invocation Manager

Invocation Manager는 엔진 컨테이너에서 컴포넌트(서블릿/JSP, Stateless Session Bean, MDB)를 호출

하는 경우에 사용하는 리소스에 대해 Logging을 남기거나 반환하는 작업을 한다. 이 구성요소를 위해 3가

지 모드 중 하나를 선택할 수 있다.

설명모드

아무런 동작을 하지 않는다.NoAction

컴포넌트 호출시 반환되지 않은 리소스에 대한 로그를 남긴다.(기본값)Warning

컴포넌트 호출시 반환되지 않은 리소스에 대한 로그를 남기고 이를 닫아준다.AutoClose

1.4.5. 디폴트 엔진 컨테이너

엔진 컨테이너는 JEUS Manager가 실행되는 JVM과는 다른 JVM에서 실행된다. 이것은 애플리케이션의

오류로 인해 엔진 컨테이너에 문제가 발생하더라도 JEUS Manager에는 영향을 주지 않기 위한 구조이다.

그러나 명시적으로 엔진 컨테이너의 이름을 'default'로 정함으로써, JEUS Manager가 실행되는 JVM에서

엔진 컨테이너를 실행 시킬 수 있다. Default 엔진 컨테이너는 주로 개발 환경에서 여러 엔진 컨테이너를

운영할 필요가 없을 때 사용된다.


1.4.6. JEUS Manager 감시 및 Self-Down 기능

보통 모든 엔진 컨테이너는 JEUS Manager가 실행되는 JVM과는 다른 JVM에서 실행된다. 이것은 엔진

컨테이너나 혹은 그것에 포함된 엔진들에 문제가 발생할 경우 JEUS Manager에는 영향을 주지 않기 위한

구조이다.

그러나 이와 반대로 JEUS Manager에 문제가 생길 경우, 엔진 컨테이너에서 운영되는 애플리케이션들이

JEUS Manager의 서비스를 이용할 수가 없기 때문에 정상적으로 진행되지 않을 수 있다.

따라서 엔진 컨테이너가 JEUS Manager의 상태를 주기적으로 감시하고, 만약 JEUS Manager에 이상이

생길 경우 자체적으로 다운(Self-Down)하는 기능을 제공한다.

참고

Default 엔진 컨테이너의 경우 JEUS Manager 감시 및 Self-Down 기능이 필요 없으므로 사용하지 않

는다.

JEUS Manager 감시의 상태 전이

엔진 컨테이너가 JEUS Manager의 상태를 잘못 판단하거나 순간적인 부하로 인해 잠시동안 비정상 상황

이 되는 경우에 엔진 컨테이너가 Self-Down해 버리면 문제가 있을 수 있다. 따라서 JEUS Manager 감시

는 다음과 같은 4단계로 나눠서 상태를 최대한 올바르게 판단할 수 있도록 한다.

[그림 1.5] Manager 감시의 상태전이

INDOUBT 상태 지속시

지정된 횟수만큼 재시도

실패/성공

NO_STATUS

ALIVEINDOUBT

FAIL

설명상태

JEUS Manager 감시를 하기 전의 초기 상태이다.NO_STATUS

JEUS Manager가 올바로 동작하고 있는 상태이다.ALIVE

JEUS Manager의 동작이 의심스러운 상태이다.INDOUBT

예) JEUS Manager가 일시적으로 오동작하고 있거나 실제 JEUS Manager에 이상이

생겼을 경우


설명상태

JEUS Manager 감시의 상태가 지속적으로 특정 횟수 이상으로 INDOUBT상태이기

때문에, 비로소 JEUS Manager에 이상이 생겼다고 판별한 상태이다(JEUS Manager

의 상태가 FAIL일 경우, 엔진 컨테이너는 Self-Down동작을 수행한다).

FAIL

JEUS Manager 감시 방법

JEUS Manager 감시의 경우 다음의 2가지 종류 중 하나를 선택하여 사용할 수 있으며, JEUS Manager 감

시(Self-Down기능)를 사용하지 않을 수도 있다.

설명구분

JEUS Manager에서 내부적으로 사용하는 Beacon 서비스를 이용하는 방법으로 JEUS

고유의 통신 방법을 이용한다.

Beacon

JMX를 이용하여 JEUS Manager에 존재하는 MBean 객체를 Query하여 상태를 확인

한다.

JMX

JEUS Manager 감시 및 Self-Down 기능을 사용하지 않는다.None

참고

1. JEUS Manager 감시를 사용할 경우, 사용하는 감시 로직의 종류에 상관없이 결국 JEUS Manager

프로세스의 PID의 유일성(Unique)을 이용하여 Manager의 상태를 판별한다.

2. 아무 설정을 하지 않았을 경우 Beacon을 사용하며 자세한 설정은 "JEUS Manager 감시의 설정"을

참조한다.

JEUS Manager 감시의 설정

다음과 같은 엔진 컨테이너 옵션으로 JEUS Manager 감시(Self-Down기능)를 세부적으로 조정할 수 있다.

JEUS Manager 감시의 상태전이의 경우 위의 "JEUS Manager 감시 방법"을 참조한다.

● -Djeus.container.monitor.type

– JEUS Manager 감시의 종류를 선택한다.

– String 형식으로 지정하며 "beacon", "jmx", "none"을 선택할 수 있다.(기본값 : "beacon")

– 다음은 설정 예제이다.

-Djeus.container.monitor.type="none"

● -Djeus.container.monitor.period

– JEUS Manager 감시를 할때의 Heart Beating주기를 설정한다.(기본값: 30초 (단위: ms))



-Djeus.container.monitor.period=30000

● -Djeus.container.monitor.retry

– JEUS Manager 모니터링할 때 실패로 인한 재시도 횟수로 한번이라도 실패할 경우 INDOUBT상태가

된다.(기본값: 5번 (단위: int))


-Djeus.container.monitor.retry=5

● -Djeus.server.maxdowntime

– JEUS Manager 감시 후 JEUS Manager가 FAIL 상태일 경우 엔진 컨테이너를 자동 down할 때, 지정

된 시간만큼 down을 기다린다. 만약 설정 값이 0일 경우 timeout기능을 사용하지 않으며, 엔진 컨테

이너가 정상 down이 될때까지 무한히 기다린다.(기본값: 0 (단위: ms))


-Djeus.server.maxdowntime=300000

● -Djeus.server.beaconConnectTO

– JEUS Manager 감시 종류 중 "beacon"을 사용할 때, Connection Timeout을 지정한다.(기본값: 30초

(단위: ms))


-Djeus.server.beaconConnectTO=30000

● -Djeus.server.beaconReplyReadTO

– JEUS Manager 감시 종류 중 Beacon을 사용할 때, JEUS Manager로부터의 응답(Reply) Timeout을

지정한다.(기본값: 10초 (단위: ms))


-Djeus.server.beaconReplyReadTO=10000


1.5. Class Loader의 구조JEUS에서 지원하는 Isolated Class Loader와 Shared Class Loader에 대해서 설명한다.

1.5.1. Isolated Class Loader

JEUS는 애플리케이션 간에 클래스가 중복되어 발생하는 문제를 방지하기 위해 애플리케이션마다 서로

다른 클래스 로더를 사용한다. 이를 Isolated Class Loader(이하 Isolated)라고 하는데, Java EE 표준은

이 방식을 기본으로 사용할 것을 권장하고 있으며, JEUS도 그 권고를 따르고 있다.

참고

JEUS5.0 이하 버전에서는 Shared 클래스 로더(이하 Shared) 방식을 기본적으로 사용하기 때문에

하위 호환성을 위해 그 방식을 계속 제공한다. 하지만 Shared 방식을 사용하는 것을 권장하지 않기

때문에 아무런 설정을 하지 않았다면 기본적으로 Isolated 방식을 사용하게 된다.

다음은 Isolated Class Loader 계층 구조이다.

[그림 1.6] Isolated Class Loader 계층 구조

JEUS root class loader

Web context class loader


EJB class loader

EJB class loader

이 구조에서는 각 애플리케이션의 웹 모듈의 클래스 로더가 그 애플리케이션의 EJB 클래스 로더의 하위

에 존재한다. 그리고 한 애플리케이션의 클래스 로더는 다른 애플리케이션의 클래스 로더에 클래스를 요

청하지 않는다. Java EE 표준은 애플리케이션이 다른 애플리케이션의 인터페이스를 필요로 하는 경우,

그 인터페이스들을 같이 패키징하도록 규정하고 있으므로 다른 애플리케이션의 클로스 로더를 참조할 수

없다.

클래스를 공유해서 사용하지 않기 때문에 한 애플리케이션을 다시 Deploy할 때 다른 애플리케이션도 같

이 다시 Deploy할 필요가 없어진다. 이 클래스 로더 구조를 제대로 사용하기 위해서는 결국 연관된 애플

리케이션끼리 EAR로 묶어서 하나의 애플리케이션으로 만드는 작업이 필요하다.


1.5.2. Shared Class Loader

웹 클래스 로더가 EJB 클래스 로더로 클래스를 요청할 수 있다. EJB 모듈 클래스 로더 중 하나가 다른 EJB

모듈 클래스 로더로 필요한 클래스를 요청할 수도 있다. 이처럼 서로 다른 애플리케이션 간에 클래스 로더

를 공유하는 것을 Shared Class Loader라고 한다.

다음은 Shared Class Loader 계층 구조이다.

[그림 1.7] Shared Class Loader 계층 구조


Web class loader

EJB class loader

EJB module class loader


다음은 각 애플리케이션의 클래스 로더에 대한 설명이다.

설명구분

시스템 라이브러리와 JDBC 드라이버, 애플리케이션 공유 라이브러리 등을

로딩할 때 사용한다.


웹 애플리케이션에서 사용하는 클래스를 로드할 때 사용된다.Web class loader

웹 컨텍스트에 해당되는 서블릿 클래스를 로딩한다.Web context class loader

EJB 엔진에서 필요로 하는 클래스를 로딩한다.EJB class loader

특정 EJB 모듈의 클래스와 라이브러리를 로딩한다.EJB module class loader

참고

JEUS5.0 이하 버전에서는 애플리케이션이 다른 애플리케이션의 EJB를 요청할 때 해당 EJB의 인터

페이스와 클래스가 없어도 클래스 로더를 공유함으로써 필요한 클래스를 찾을 수 있다. 하지만 하나

의 애플리케이션을 다시 Deploy할 경우나 UnDeploy할 경우에는 다른 관련 애플리케이션들을 모두

다시 Deploy해야 하는 문제가 발생한다.


제2장 JEUS 설정

본 장에서는 JEUS의 구성 요소들인 JEUS Manager, 엔진 컨테이너, 엔진의 설정 방법 및 기타 부가 기능

의 설정 방법에 대해 설명한다.

2.1. 개요JEUS의 주요 설정은 JEUSMain.xml 파일에서 설정된다. 이 파일은 다음의 경로에 저장되어 있다. 경로에

포함되어 있는 <node-name>은 기본적으로 JEUS가 동작하는 호스트 이름으로 지정된다.

JEUS_HOME\config\<node-name>

[그림 2.1] JEUSMain.xml 위치

johan

JEUS_HOME\

config\

X JEUSMain.xml

JEUSMain.xml 파일의 최상위 XML 태그는 <jeus-system> 이다.

<jeus-system xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

...

</jeus-system>

참고

이곳에서는 JEUSMain.xml 파일에 대하여 개략적으로 설명하고 있으므로 전반적인 자세한 내용은

"JEUS_HOME\docs\reference\schema\index.htm"에 있는 XML Reference 예제를 참조한다. 앞으로

의 예에서 root element의 xmlns=http://www.tmaxsoft.com/xml/ns/jeus 설정은 생략하겠다. 다음 절

에서 문서 편집기 등을 이용해서 XML 을 직접 편집하는 방법으로 JEUSMain.xml을 수동으로 설정

하는 방법에 관하여 설명하고 있다.

WebAdmin을 이용하여 JEUSMain.xml을 설정하는 방법은 "JEUS WebAdmin 안내서"를 참조한다.

2.1.1. JEUS Manager의 설정

JEUS Manager의 설정과 관련해서 앞으로 설명할 각종 속성들은 모두 JEUSMain.xml 파일의 <jeus-system>

Element 내에 설정되어야 한다.

제2장 JEUS 설정 17

다음의 XML 예제는 JEUSMain.xml 파일의 내용 중 최상위 레벨의 XML 구조이다.

[예 2.1] JEUS Manager의 설정 : <<JEUSMain.xml>>

<jeus-system>

<node>

. . . 

</node>

<node>

. . .

</node>

<node>

. . .

</node>

<naming-server>

. . . 

</naming-server>

<security-manager>

. . . 

</security-manager>

<resource>

. . . 

</resource>

<application>

. . . 

</application>

</jeus-system>

예제에는 노드 관련 설정 이외에 하나의 JEUSMain.xml 파일 안에 한 번씩만 설정할 수 있는 속성으로

JNDI Naming Server, Security Manager의 설정을 포함하고 있다. 만약 이 태그들을 설정하지 않으면 기

본값을 사용한다. 또한 등록하고 싶은 Resource, Deploy할 애플리케이션에 대한 설정 태그도 포함하고

있다.

다음은 설정에 사용되는 각 태그에 대한 설명이다.

설명태그

각각의 JEUSMain.xml 파일은 여러 개의 노드에 관한 설정을 가지고 있을 수

있지만, JEUS Manager 는 그 중 단 한 개의 설정만을 따라서 동작한다.

<node>

동작에 대한 자세한 내용은 “제4장 JEUS 클러스터링”에서 설명하도록 한다.

단일 노드에 관한 설정 방법은 “2.2. 노드 설정”을 참조한다.

“제6장 JNDI Naming Server”를 참조한다.<naming-server>

“JEUS Security 안내서”의 “제2장 보안 시스템의 설정”을 참조한다.<security-manager>


설명태그

“제7장 External Resource”를 참조한다.<resource>

JEUS가 기동할 때 디플로이되는 애플리케이션을 지정한다.<application>

각각의 JEUSMain.xml 파일은 여러 개의 노드에 관한 설정을 가지고 있을 수 있지만, JEUS Manager는 그

중 단 한 개의 설정만을 따라서 동작한다. 동작에 대한 자세한 내용은 “제4장 JEUS 클러스터링”에서 설명

한다. 단일 노드에 관한 설정 방법은 “2.2. 노드 설정”을 참조한다. 위의 예제를 보면, 실제 JEUS Manager

가 사용할 내용은 한 개뿐인데도 여러 개의 노드관련 설정이 들어 있는 것을 볼 수 있다. 이중에서 실제 사

용될 부분은 현재 컴퓨터의 호스트 이름과 동일한 이름을 가지고 있는 부분의 설정이다. 이와 관련된 내용

은 “제4장 JEUS 클러스터링”에서 자세히 설명한다.

2.1.2. 실행 스크립트에 Java –D 파라미터 추가

jeus 명령은 JEUS Manager를 실행하는 스크립트이다. JEUSMain.xml 설정과는 별개로 ‘jeus’ 스크립트

를 수정하여 런타임에 필요한 파라미터를 제공할 수 있다.

옵션 추가는 ‘jeus’ 명령이 JVM 을 실행하여 JEUS Manager가 동작하도록 하기 위해 작성된 스크립트인

관계로 특정 위치(JEUS_HOME\bin\)에서 실행 스크립트(jeus)를 열어서 편집하는 간단한 작업이 된다.

참고

1. 소개한 “–D” 옵션의 파라미터들은 이 스크립트에서 반드시 사용되어야만 한다(-classpath 다음에

적는다). 이 파라미터를 사용해서 JEUS Manager와 JEUS의 실행을 조정할 수 있다. 예를 들어 –D

파라미터를 이용해서 JEUS base port 또는 JEUS home 경로 등을 수정할 수 있다.

2. 명령의 종류와 용도에 관해서는 “JEUS Reference Book”의 “제3장 jeus”에서 자세히 확인할 수 있

다.

2.2. 노드 설정JEUS 노드를 JEUS 시스템에 추가 하기 위해서 <node>태그를 JEUSMain.xml에 추가해야 한다. 이 요소

는 최상위의 <jeus-system> 내에 위치한다. 적어도 하나의 노드가 각 JEUSMain.xml에 설정되어야만 한

다.

[예 2.2] 노드 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

. . .

</node>

. . .

</jeus-system>


노드 클러스터를 설정하는 경우 “2.2.3. 노드 클러스터링 설정”에서 설명하는 특별한 설정 구조를 적용할

필요가 있다.

2.2.1. 기본 노드 설정

다음은 기본 노드 설정에 대한 예이다. XML 설정 부분에서 노드의 머신 이름은 “johan”이고 엔진 컨테이

너가 순차적으로 시작되며, Class FTP 서버와 WebAdmin을 사용함을 알 수 있다.

[예 2.3] 기본 노드 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan</name>

<listener>

<backlog>128</backlog>

<ssl>9937</ssl>

<thread-pool>

<min>3</min>

<max>40</max>

<period>3600000</period>

<thread-pool>

</listener>

<sequential-start>true</sequential-start>

<class-ftp>true</class-ftp>

<enable-webadmin>true</enable-webadmin>

<webadmin-config>

<allowed-server>192.168.*.*</allowed-server>

<allowed-server>211.180.1.*</allowed-server>

</webadmin-config>

. . .

</node>

. . .

</jeus-system>

다음은 설정에 사용되는 각 태그에 대한 설명이다.

● <name>

– JEUS 시스템 내에서 노드의 식별자로 클러스터링 환경 내에서 유일한 이름을 가진다.

– 기본적으로 노드의 이름은 노드와 노드 관리자가 동작하고 있는 물리적인 호스트의 네트워크 식별

이름과 동일한 이름이다. 이는 시스템 관리자에 의해 설정되고 UNIX에서 “uname –n” 명령을 수행하

거나 Windows 환경에서 컴퓨터의 네트워크 이름을 확인하여 얻을 수 있다.

예를 들어 만약 어떤 물리적 머신의 네트워크 이름이 “johan”이라면, 그곳에서 동작하는 JEUS 노드

의 이름 또한 “johan”이어야 한다. 런타임시에 이 이름은 java.net.InetAddress. getLocalHost().getH


ostName()을 통해서 얻을 수 있다. 단, Virtual Host 기능을 사용하면 노드의 이름을 임의로 지정할 수

있다.

주의

노드의 이름은 영문자와 숫자의 조합으로만 이루어져야 하고, 영문자로 시작하는 문자열이어야 한

다.

● <listener>

– JEUS Base Port를 통해 통신하기 위해 필요한 여러 가지 설정의 집합이다. 대부분의 경우 별도로 이

설정을 하지 않아도 무방하다.

– 다음은 Listener의 하위 설정 항목에 대한 설명이다.

설명항목

JEUS System Listener Port인 JEUS Base Port에 대한 backlog값을 지정한다.<backlog>

JEUS Security System에 관련된 SSL 속성을 지정한다. 이 element를 설정하면 Jeus

Security System을 사용하는 모든 소켓 커넥션에 SSL이 적용된다.

<ssl>

JEUS System Listener Port인 JEUS Base Port에 요청되는 소켓 커넥션 처리를 위한

Thread Pool을 설정한다.

<thread-pool>

● <backup-node>

– 현재 노드가 어떤 노드에 심각한 장애가 발생할 경우 그 노드를 대신해서 동작해야 할 대상 노드의 이

름이다. 자세한 내용은 “제4장 JEUS 클러스터링”을 참조한다.

● <sequential-start>

– 엔진 컨테이너들이 순차적으로 시작될 지 여부를 결정하는 설정이다.

– false로 설정될 경우 각 엔진 컨테이너가 동시에 시작된다.(기본값: false)

● <class-ftp>

– EJB Stub을 클라이언트로 전송하기 위한 Class FTP 서버를 사용할지의 여부를 결정하는 설정이다.

– false로 설정해 놓고 EJB 클라이언트에 EJB Stub이 없다면 에러가 발생할 수 있다.(기본값: false)

● <enable-webadmin>

– WebAdmin을 사용할지 여부를 결정하는 설정이다.(기본값 : false)

● <webadmin-config>

– 해당 호스트들이 WebAdmin에 접근할 수 있도록 하는 설정이다.

– 하위 항목에 호스트 리스트를 설정한다.

설명항목

WebAdmin에 접근할 권한을 갖는 호스트 목록의 IP 주소를 설정한다.<allowed-server>


설명항목

여기에 설정된 주소의 호스트만이 WebAdmin에 접근할 수 있다. 설정되는

IP 주소에 wildcard(*)를 사용할 수 있다(예: 192.168.*.*).

그 외 JEUSMain.xml의 XML 설정 요소들에 따라 설정 가능한 노드 하부 구성 요소는 다음과 같다. 이 구

성 요소들 중 몇몇은 복잡하고 별도의 처리를 요구하기도 한다. 이런 구성 요소에 대해서는 다음에 명시한

관련 부분을 참고한다.

관련 부분XML 요소 이름구성 요소

“2.3. 엔진 컨테이너 설정”<engine-container>엔진 컨테이너

“제11장 Logging”<system-logging>Logging

“10.2. 중앙 세션 서버”<session-server>중앙 세션 서버

“10.3. 분산 세션 서버”<session-router-config>분산 세션 서버

"JEUS JMX 안내서"<jmx-manager>JMX 관리자

"JEUS Schduler 안내서"<scheduler>스케줄러

"JEUS Client Application 안내서"<enable-jnlp>JNLP Server

2.2.2. 가상 노드 설정

가상 노드는 JEUS_HOME\config\vhost.properties 파일에 설정한다.

[예 2.4] 가상 노드 설정 : <<vhost.properties>>

jeus.vhost.enabled=true

node1=myhost:9736

node2=myhost:9836

node3=yourhost:9936

node4=yourhost:10036

각 프로퍼티의 설명은 다음과 같다.

설명프로퍼티

가상 호스트 설정을 적용할지 여부를 지정한다.jeus.vhost.enabled

각 가상 호스트를 설정한다. value에 {real_hostname}[:{port}] 형태로 지정한다.{vitual_hostname}

지정된 가상 호스트로 JEUS Manager를 실행하기 위해서는 시스템 프로퍼티 "jeus.baseport"를 사용해서

해당 Base Port를 설정하면 해당 노드 이름이 기동된다. 기본적으로 사용하는 vhost.properties 파일이 아

닌 다른 파일을 사용하려면 JEUS의 시스템 프로퍼티인 'jeus.vhost.properties'를 통해 다른 파일을 지정할

수 도 있다.


참고

가상 호스트를 사용하는 경우에는 JEUS의 config 디렉터리의 node 디렉터리도 가상 노드 이름을 사

용해야 하며 이 노드 내의 엔진 컨테이너나 엔진들도 가상 노드 이름을 노드 이름인 것처럼 사용해야

한다. 또한 jeusadmin 등 노드 이름을 사용하는 모든 곳에서 가상 노드 이름을 사용하면 그 가상 노

드 이름에 해당하는 JEUS Manager를 지칭하게 된다.

2.2.3. 노드 클러스터링 설정

여러 노드로 구성된 JEUS 클러스터링을 설정하기 위해서는 클러스터에 속한 각각의 노드들에 대해 <node>

요소가 있어야 한다. 클러스터에 속한 모든 노드들은 JEUSMain.xml 파일에 같은 설정을 가지고 있어야

한다. 자세한 사항은 “제4장 JEUS 클러스터링”을 참조한다.

2.3. 엔진 컨테이너 설정JEUSMain.xml의 <node>하위에 <engine-container>를 추가한다.

[예 2.5] 엔진 컨테이너 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

. . .

<engine-container>

. . .

</engine-container>

. . .

</node>

. . .

</jeus-system>

2.3.1. 기본 설정

다음은 엔진 컨테이너의 기본 설정의 예제이다.

[예 2.6] 엔진 컨테이너 기본 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

. . .

<engine-container>

<name>mycontainer</name>

<base-port>3031</base-port>


<command-option>-Xms64m -Xmx128m</command-option>

<start-on-boot>false<start-on-boot>


<user-class-path>

c:\mylib\classes;c:\mylib\lib\mylib.jar

</user-class-path>

<enable-interop></enable-interop>

<use-MEJB>true</use-MEJB>

. . .

</engine-container>

. . .

</node>

. . .

</jeus-system>

다음은 설정 태그에 대한 설명이다.

설명태그

임의로 엔진 컨테이너의 이름을 선택할 수 있다. 만약 이름이 “default”라고 설정

되면 Default 엔진 컨테이너로 구동된다.

<name>

엔진 컨테이너의 이름으로는 영문자와 숫자의 조합만 가능하다. 단 영문자부터

시작해야 한다.

엔진 컨테이너가 사용할 ID를 0 이상 128 미만의 정수로 입력한다. 트랜잭션 매

니저가 트랜잭션 ID를 생성할 때 사용하므로 recovery할 때 이 값은 fail 이전과

이후가 같아야 한다.

<id>

기본값은 name의 hashcode를 바탕으로 생성한다. 다른 엔진 컨테이너와 중복

되면 컨테이너 기동이 실패한다.

엔진 컨테이너별로 Listen Port를 사용할 때 기본적으로 Base Port + 15 + 컨테

이너 ID * 10 의 값이 컨테이너의 Base Port로 사용된다.

<base-port>

트랜잭션 매니저가 트랜잭션 ID를 만들때에 사용하므로 recovery할 때 이 값은

fail 이전과 이후가 같아야 한다.

다른 엔진 컨테이너와 겹치면 컨테이너 기동이 실패한다.

엔진 컨테이너를 실행하기 위해 개별적인 JVM에 추가할 파라미터들을 선언하

는 데 사용된다. 지정 가능한 JEUS 파라미터들의 목록은 “JEUS Reference Book”

의 “1.2. 서버 시스템 프로퍼티”를 참고한다.

<command-option>

표준 JVM 파라미터들도 설정 가능하다.

기동할 때 컨테이너를 띄울지를 정한다. 값이 false이면 기동할 때 컨테이너를

띄우지 않는다.(기본값: true)

<start-on-boot>

boolean 값으로 만약 “true”라고 설정하면, 컨테이너에 존재하는 모든 엔진들이

순차적으로 시작된다.(기본값: true)

<sequential-start>


설명태그

예를 들어 WS 엔진은 반드시 WS 엔진이 사용하는 서블릿 엔진이 기동되기 전

에 시작되어야 한다. 따라서 JEUSMain.xml에서 서블릿 엔진 전에 WS 엔진을

정의하고 sequential start 값을 “true”라 선택하면 WS 엔진이 먼저 기동된다.

시스템 클래스 패스를 추가한다.<user-class-path >

디폴트(default) 엔진 컨테이너에는 적용되지 않는다. 디폴트 엔진 컨테이너에

적용하기 위해서는 jeus.server.classpath system property를 사용하여야 한다.

디폴트 컨테이너가 아닌 컨테이너에 대해서는 JEUSMain.xml의 설정이 시스템

프로퍼티에 우선한다. 구분자는 ";" (UNIX의 경우 “:”)을 사용한다.

RMI/IIOP 상호 운영성(interoperability)에 대해서 설정한다. 이 설정이 있으면 상

호 운영을 enable 한다.(기본적으로 disable 되어 있다)

<enable-interop>

EJB RMI/IIOP를 사용한다면 반드시 설정되어야 한다.

J2EE Management 스펙에서 제시하는 MEJB를 사용할 것인지를 설정한다. 사

용하지 않는다면 MEJB를 Deploy하지 않는다.(기본값: false)

<use-MEJB>

애플리케이션 archive 파일들을 넣을 디렉터리를 지정한다. 상대 경로인 경우에

는 JEUS_HOME path에서의 상대 경로이다. 애플리케이션은 이 element의 순서

대로 검색된다.

<application-path>

(기본값: webhome/app_home ( jeus.apphome system property을 설정했다면

이 값이 기본값이 된다)

2.3.2. Invocation Manager 설정

Invocation manager는 엔진 컨테이너에서 서블릿/JSP, EJB Stateless Session Bean, 그리고 MDB와 같

은 Stateless 메소드를 호출하는 동안 사용하는 외부 리소스(external resource)인 JDBC 커넥션과 Webt

커넥션을 추적하여 커넥션이 닫히지 않은 경우 모드에 따라 적절한 처리를 해준다.

Invocaiton manager는 JEUSMain.xml의 각 엔진 컨테이너 요소 하위에 하나의 <invocation-manager-

action>으로 설정된다.

다음은 Invocation Manager 설정에 대한 예로 XML 부분은 무상태 메소드 호출 후 반환된 열려진 자원을

Invocation manager가 자동으로 닫도록 한다.

[예 2.7] Invocation Manager 설정 : <<JEUSMain.xml>>

<jeus-system>

<node>

. . .

<engine-container>

. . .

<invocation-manager-action>

AutoClose


</invocation-manager-action>

. . .

</engine-container>

. . .

</node>

. . .

</jeus-system>


● <invocation-manager-action>

설명설정값

기능을 사용하지 않는다.NoAction

만약 한 자원이 Stateless 메소드 호출 동안 사용되었지만 반환할 때 닫지 않게 될 경

우 이벤트가 컨테이너 로그에 warning 메시지로 기록된다.

Warning

만약 한 자원이 Stateless 메소드 호출 동안 사용되었으나 반환할 때 닫히지 않는다면

자원이 자동적으로 닫힌다.

AutoClose

2.3.3. 데이터베이스 매핑 설정

엔진 컨테이너 단위로 데이터베이스 매핑을 하려면 JEUSMain.xml의 <engine-container><res-ref><jndi-

info> 태그를 사용해서 설정한다.

[예 2.8] Database Mapping 설정 : <<JEUSMain.xml>>

<jeus-system>

<node>

. . .

<engine-container>

. . .

<res-ref>

<jndi-info>

<ref-name>A</ref-name>

<export-name>B</export-name>

</jndi-info>

</res-ref>

</engine-container>

. . .

</node>

. . .

</jeus-system>



설명태그

데이터소스를 위한 레퍼런스 이름을 선언한다. 이 이름이 애플리케이션 코드에서

lookup할 때 사용하는 이름이다.

<ref-name>

태그에는 실제 작업할 데이터소스의 export-name을 지정한다.

실제 datasource/database의 JNDI 이름이다.

<export-name>

위 태그에서 정의된 매핑은 해당 엔진 컨테이너에서만 적용된다.

2.3.4. Lifecycle Method Invocation 설정

엔진 컨테이너의 각종 lifecylcle 이벤트에 호출하고 싶은 메소드를 지정할 수 있다.

<lifecycle-invocation> 태그를 사용하고 다음과 같은 하위 태그를 설정한다.

[예 2.9] Lifecycle Method Invocation 설정 : <<JEUSMain.xml>>

<jeus-system>

<node>

. . .

<engine-container>

. . .

<lifecycle-invocation>

<class-name>lifecycle.LifeCylcleTester</class-name>

<invocation>

<invocation-method>

<method-name>sleep</method-name>

</invocation-method>

<invocation-type>READY</invocation-type>

</invocation>

</lifecycle-invocation>

</engine-container>

. . .

</node>

. . .

</jeus-system>


● <class-name>

– lifecycle event의 callback 메소드가 존재하는 fully qualified class name을 지정한다.

● <invocation>

– 클래스 내의 invocation 세부 정보를 설정한다.


– 다음은 하위 설정 항목이다.

• <invocation-method> : invocation에 사용될 메소드를 지정한다.

• <invocation-argument> : 메소드를 호출할 때 사용하는 argument를 지정한다.

• <invocation-type> : 메소드가 호출되는 시점을 지정한다.

설명구분

엔진 컨테이너가 시작되고 엔진들이 띄워지기 전의 시점이다.BOOT

엔진 컨테이너가 시작되고 이 엔진 컨테이너에게 지정된 애플리케이션이

Deploy되기 전의 시점이다.

BEFORE_DEPLOY


Deploy된 후의 시점이다.

AFTER_DEPLOY


Deploy된 후 서비스가 준비된 시점이다.

READY

엔진 컨테이너가 down 명령을 받았을 때 이 엔진 컨테이너에서 운영중인 애

플리케이션들을 UnDeploy하기 전의 시점이다.

BEFORE_UNDEPLOY

엔진 컨테이너가 down 명령을 받았고 이 엔진 컨테이너에서 운영중인 애플

리케이션들을 UnDeploy한 후의 시점이다.

AFTER_UNDEPLOY

<lifecycle-invocation>에 등록하는 클래스는 일반 Java 클래스이다. 그것을 JEUS를 실행할 JDK의 javac

로 컴파일해서 원하는 이름의 jar 파일로 묶은 다음, JEUS_HOME/lib/system에 위치시킨다.

[예 2.10] <<LifeCycleTester.java>>

package lifecycle;

public class LifeCylcleTester {

public void sleep() {

try {

System.out.println("Sleeping for 15 seconds ....");

Thread.sleep(15000L);

} catch (Exception e) {

//ignored

}

}

}

2.3.5. 기타 엔진 컨테이너 설정

다음은 엔진, 트랜잭션 매니저, JMX 매니저 스케줄러 서버 설정에 대한 예이다.


[예 2.11] 기타 엔진 컨테이너 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

. . .

<engine-container>

<name>mycontainer</name>


<command-option>-Xms64m -Xmx128m</command-option>


<user-class-path>

c:\mylib\classes;c:\mylib\lib\mylib.jar

</user-class-path>

<security-switch>true</security-switch>

<engine-command>

. . .

</engine-command>

<tm-config>

. . .

</tm-config>

<jmx-manager>

. . .

</jmx-manager>

<scheduler>

. . .

</scheduler>

. . .

</engine-container>

. . .

</node>

. . .

</jeus-system>

각 항목을 설정하기 위해서는 각각 해당하는 장을 참고한다. 다음은 이 구성요소들과 설정을 위해 필요한

XML 요소와 자세한 정보를 위해 참고할 장에 대한 설명이다.

관련 부분XML 요소 이름구성 요소

“2.4. 엔진 설정”<engine-command>엔진

“제9장 트랜잭션 매니저”<tm-config>트랜잰션 매니저

"JEUS JMX 안내서"<jmx-manager>JMX Manager

"JEUS Scheduler 안내서"<scheduler>스케줄러

“제11장 Logging”<user-logging>, <system-logging>Logging


2.4. 엔진 설정엔진을 설정하려면 JEUSMain.xml 및 각 엔진 설정 파일(EJBMain.xml, WEBMain.xml, JMSMain.xml,

ws_engine.m)에서 필요한 설정을 해야 한다.

[그림 2.2] JEUS 엔진들의 디렉터리 구조

JEUS_HOME\

config\

<node name>\

X JEUSMain.xml

bin\

<nodename>_ejb_<enginename>\

X EJBMain.xml

0I jmsadmin

<nodename>_servlet_<enginename>\

X WEBMain.xml

<nodename>_jms_<enginename>\

X JMSMain.xml

0I jeusadmin

Legend:

0I: binary or executable file

X: XML document

참고

각 엔진별 설정 파일은 다은 그림의 지정된 위치에 반드시 존재해야 한다. 만약 엔진 설정 파일을 찾

지 못한다면 에러가 발생한다. 웹 서버 엔진의 설정은 다른 엔진들처럼 해당 디렉터리에서 가져오는

것이 아니라 내장 Web Server가 설치된 디렉터리의 ws_engine.m 파일을 사용한다는 점에 유의한

다.

2.4.1. 엔진 종류 설정

각 엔진은 JEUSMain.xml에서 <engine-container> 요소 하위에 <engine-command> 요소에 설정한다.

반드시 하나 이상의 <engine-command> 요소가 각 <engine-container> 요소에 있어야 한다.

다음은 모든 엔진 종류가 포함된 XML 예제이다.

[예 2.12] 엔진 종류 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .


<node>

. . .

<engine-container>

. . .

<engine-command>

<type>ejb</type>

<name>engine1</name>

</engine-command>

<engine-command>

<type>servlet</type>


</engine-command>

<engine-command>

<type>jms</type>


</engine-command>

<engine-command>

<type>ws</type>


</engine-command>

. . .

</engine-container>

. . .

</node>

. . .

</jeus-system>


설명태그

엔진의 설정 파일을 찾을 수 있는 엔진의 홈 디렉터리의 엔진 이름 부분과 일

치해야 한다. 예를 들어서 만약 엔진 홈 디렉터리가 JEUS_HOME\config\jo

han\johan_servlet_engine1\ 이라면 서블릿 엔진의 이름은 “ engine1” 이다.

<name>

다음 중에 하나를 설정한다.<type>

- ejb

- servlet

- jms

- ws

엔진의 logging 설정을 가지고 있다. 자세한 설정 방법은 “제11장 Logging”을

참조한다.

<system-logging>

선택 사항이므로 엔진의 로그를 따로 남기고 싶지 않으면 설정하지 않아도

된다. 그러면 엔진 컨테이너 로그나 컨테이너 로그가 없을 때는 서버 로그에

남게된다.


2.4.2. 웹 서버 엔진 설정

웹 서버 엔진이 엔진 컨테이너에 추가되었다면 웹 서버 설정 파일 또한 반드시 설정해야 한다.

설정 파일의 이름은 'ws_engine.m'이 되어야 하고 JEUS 웹 서버의 홈 디렉터리(JEUS_HOME\webserver)

아래의 config 폴더에 위치해야 한다. 해당 파일이 존재하지 않을 경우 이전에 생성된 wsconfig 파일을 가

지고 웹 서버를 가동하게 된다.

참고

자세한 사항은 "JEUS Web Container 안내서"와 "WebtoB 매뉴얼"을 참고한다.

2.5. JEUS 튜닝 고려사항JEUS를 설정할 때 다음을 고려한다.

● 엔진 컨테이너의 기동시간을 줄이기 위해 순차적인 시작 옵션을 끈다. 멀티 프로세서를 가지고 있는 머

신의 경우 기동시간을 줄여줄 수 있다.

● 엔진 컨테이너 안의 엔진에서 동작하는 애플리케이션이 보안 인증과 권한 검사를 필요로 하지 않는다

면 보안기능을 사용하지 않도록 설정한다.

위와는 별도로 하위 구성요소들에 대한 튜닝도 확인해야 한다. 이에 대한 설명은 각 구성요소에 대한 장을

참고한다.


제3장 JEUS 제어 및 모니터링

본 장에서는 Command Line에서 JEUS를 제어하고 모니터링 하는 방법을 설명한다. 설명한 내용은 We

bAdmin을 통해서도 할 수 있으므로 Command Line에 익숙하지 않다면 WebAdmin을 사용할 것을 권장한

다.

참고

jeus와 jeusadmin 콘솔 툴에 관한 자세한 사항은 “JEUS Reference Book”의 “제3장 jeus”와 “JEUS

Reference Book”의 “4.2.3. 공통 명령어”를 참조한다. WebAdmin을 이용한 JEUS Manager 컨트롤은

"JEUS WebAdmin 안내서"를 참조한다.

3.1. JEUS 제어 및 모니터링

3.1.1. JEUS Manager 기동과 종료

JEUS Manager는 ‘jeus’ 실행 스크립트에 의해서 일반적인 형태로 실행된다.

JEUS Manager 기동

1. JEUS Manager를 실행하여 대기 상태가 되도록 하기 위해서는 JEUS_HOME\bin\ 경로가 시스템 경로

로 설정되어 있거나 해당 디렉터리로 이동 후 실행해야 한다.

c:\jeus\bin> jeus

[2009.04.14 17:03:12][0][b213] [johan-10] [MGR-0411] virtual host name of this man

ager : johan

. . .

[2009.04.14 17:03:15][0][b213] [johan-10] [MGR-0000] JEUS Server is starting - JEU

S 6.0 (Fix#6) (6.0.0.6-b213)

. . .

[2009.04.14 17:03:17][2][b213] [johan-10] [MGR-0173] JNDI Naming Server started

. . .

[2009.04.14 17:03:21][2][b213] [johan-10] [MGR-0248] Jeus Manager is Ready

"Jeus Manager is Ready"라는 로그가 출력되면 성공적으로 JEUS Manager가 Started 상태가 된 것이

다.

2. 다음의 예제는 jeusadmin 툴을 johan 이라는 노드에 접근하도록 실행하는 방법이다. 사용자 ID 와 패스

워드를 입력한다.

제3장 JEUS 제어 및 모니터링 33

jeusadmin johan

Login name>administrator

Password>

3. 다른 콘솔에서 jeusadmin 명령을 실행해서 JEUS Manager를 기동한다.

johan>boot

4. JEUS Manager 창에 기동 관련 정보들이 표시되고, 작업이 성공적으로 끝나면 jeusadmin 창에 다음의

메시지가 출력된다.

johan boot done

johan_container1

jeusadmin 창의 마지막에 출력된 메시지는 “johan_container1”라는 엔진 컨테이너가 동작하기 시작했

다는 내용이며, 그것은 JEUS Manager가 현재 정상적으로 동작하고 있다는 의미이다.

위와 같이 jeusadmin을 통해 JEUS Manager를 기동할 수도 있지만 'jeus' 실행 스크립트에 사용자 ID와 패

스워드를 입력하면 한번에 기동할 수 있다.

jeus -Uadministrator -P1111111

. . .

[2009.04.14 17:10:00][2][b213] [johan-10] [MGR-0248] JEUS Manager is READY

. . .

[2009.04.14 17:10:13][2][b213] [container1-10] [MGR-0103] engine container[johan_c

ontainer1] is READY

[2009.04.14 17:10:13][2][b213] [container1-10] [MGR-0101] currently running engine

s of engine container[johan_container1] : [johan_servlet_engine1, johan_ejb_engine

1, johan_jms_engine1]

[2009.04.14 17:10:14][0][b213] [johan-12] [MGR-0303] engine container[johan_contai

ner1] initialization successfully done [pid : 2000]

[2009.04.14 17:10:14][0][b213] [johan-10] [MGR-0242] JeusServer one-step booting s

uccessful : [johan_container1]

참고

하나 또는 몇몇 엔진 컨테이너가 기동되지 않았다고 하더라도 JEUS Manager는 노드가 정상적으로

기동되었다고 판단한다.

JEUS Manager 종료다음의 과정으로 JEUS Manager를 종료한다.

1. 기동 상태인 JEUS Manager를 종료하는 경우 jeusadmin에서 다음의 명령을 실행한다.

node-name> down


2. 다음 메시지는 종료 명령이 성공적으로 수행되어 JEUS Manager가 대기상태가 되었을 때 표시되는 메

시지이다.

The JEUS node [johan] is down.

JEUS Manager를 완전히 종료(not existing)하기 위해서는 jeusadmin에서 다음의 명령을 수행한다.

node-name> jeusexit

3.1.2. 노드 제어 및 모니터링

노드 기동

● 노드와 구성 요소 시작

jeusadmin 콘솔 툴에서 “boot” 명령을 사용하여 노드와 하위 구성 요소들을 시작할 수 있다.

johan>boot

johan boot done

johan_container1

johan_container2

● 클러스터된 모든 JEUS 기동

클러스터된 모든 JEUS를 기동하는 경우 -all 옵션을 사용한다.

johan>boot -all

johan:johan_default boot done

johan2:johan2_default boot done

노드 종료

● JEUS 정지

JEUS를 정지하는 경우 “down” 명령을 이용한다.

johan>down

Do you really want to shutdown the node [johan]? (y : n):>y


위와 같이 물어보지 않도록 하려면 -i 옵션을 사용한다.

johan>down -i


● JEUS 종료

JEUS를 종료하는 경우 "jeusexit" 명령을 이용한다.


johan>jeusexit

johan jeusexit successful

● JEUS 정지와 종료

정지(down)과 종료(jeusexit)를 한 번에 하려면 "down" 명령에서 -e 옵션까지 설정하거나 jeusexit를 사

용한다.

johan>down -i -e

johan down successful

johan jeusexit successful

참고

명령어에 대한 보다 자세한 정보와 jeusadmin의 수행에 대한 내용은 “JEUS Reference Book”의 “4.2.3.

공통 명령어”를 참고한다.

노드 모니터링

● 노드 목록 조회

jeusadmin에서 “nodelist” 명령을 사용하여 현재 JEUS 클러스터에 활성중인 노드들의 목록을 얻는 것

으로 시작한다.

johan>nodelist

johan

johan2

모니터링할 노드를 선택하여 jeusadmin을 통해 연결한다.

c:\jeus>jeusadmin johan -Ujeus -Pjeus

JEUS 6.0 (Fix#8) JEUS administration tool

johan>

● 특정 노드의 상태와 하위 구성 요소의 정보 조회

"pidlist”같은 “<xyz>list” 명령을 특정 노드의 상태와 활성중인 하위 구성요소의 정보를 얻기 위해 사용한

다.

johan>pidlist

node or container : johan, pid : 2428

node or container : johan_container1, pid : 2000

참고

명령들에 대한 보다 자세한 정보와 jeusadmin의 수행에 대한 내용은 “JEUS Reference Book”의 “4.2.3.

공통 명령어”를 참고한다.


3.1.3. 엔진 컨테이너의 제어 및 모니터링

엔진 컨테이너 제어

● 엔진 컨테이너 시작

jeusadmin에서 비활성화된 엔진 컨테이너를 시작하기 위해서 “startcon”을 사용한다.

johan>startcon

johan_container1 : READY

johan>startcon johan_container1

Succeeded to start johan_container1.

● 엔진 컨테이너 정지

활성화된 엔진 컨테이너를 정지시키기 위해 “downcon” 명령을 사용할 수 있다.

johan>downcon

johan_container1 : SHUTDOWN

johan>downcon -node johan


johan>downcon johan_container1

johan_container1 container is down successful

엔진 컨테이너 모니터링

● 엔진 컨테이너 목록 조회

jeusadmin 툴에서 “conlist” 명령을 수행하여 활성화된 엔진 컨테이너 목록을 조회할 수 있다.

johan>conlist

Engine container list of the node johan

[1] johan_container1 : READY

[2] johan_container2 : READY

● 엔진 컨테이너 엔진 이름 조회

“englist” 명령을 통해 특정 엔진 컨테이너에 속한 엔진들의 모든 이름을 조회할 수 있다.

johan>englist

========================================

engines in the container johan_container2

johan_servlet_engine2

johan_ejb_engine2

========================================

========================================

engines in the container johan_container1


johan_ejb_engine1


========================================

johan>englist johan_container1


johan_ejb_engine1

참고

명령어에 대한 자세한 설명은 “JEUS Reference Book”의 “4.2.3. 공통 명령어”를 참고한다.

3.1.4. 엔진 제어 및 모니터링

엔진 제어

● 엔진 시작과 정지

jeusadmin에서 하나의 엔진을 시작하거나 정지하기 위하여 해당 컨테이너를 시작하거나 정지해야 한

다. 이때에는 컨테이너에 있는 모든 엔진들이 함께 시작하거나 정지한다.

johan>startcon johan_container1

Succeeded to start johan_container1.

johan>downcon johan_container1


엔진들은 엔진 컨테이너가 시작될 때 자동으로 시작된다. 엔진 컨테이너는 또한 JEUS 노드가 jeusadmin

에서 “boot” 명령을 통해서 기동될 때 자동으로 시작된다. 또한 노드나 엔진 컨테이너를 종료할 때도 같

이 적용이 된다.

참고

명령어에 대한 자세한 설명은 “JEUS Reference Book”의 “4.2.3. 공통 명령어”를 참고한다.

엔진 모니터링

● 현재 노드에서 활성화된 엔진 목록 조회

jeusadmin 콘솔 툴을 이용하여 엔진을 모니터하기 위해 “allenglist” 명령만을 사용할 수 있다. 이것은 현

재 노드에서 활성화된 엔진 목록을 출력한다.

johan>allenglist

========================================

engines in the container johan_contianer1

johan_ejb_engine1


========================================


3.2. Thread 모니터링 및 제어JEUS에서는 서블릿 Thread와 EJB 리모트 Thread, 시스템 Thread Pool에 대한 모니터링 기능과 Thread

의 Stack을 확인할 수 있는 기능, 그리고 특정 Thread에 interrupt 시그널을 보낼 수 있는 기능을 제공한다.

3.2.1. Thread 모니터링

JEUS에서는 Thread를 모니터링하는 기능을 제공한다. 모니터링의 대상이 되는 Thread는 서블릿 요청

Thread, EJB 리모트 요청 Thread 그리고 시스템 Thread Pool이다.

서블릿 Thread나 EJB 리모트 요청 Thread의 모니터링 기능을 사용하면 Thread ID, Thread 이름, Thread

상태, 처리시간 등의 정보를 알 수 있고, Thread Pool 모니터링 기능을 사용하면 시스템 Thread Pool의

core size, max size, keep alive time, 그리고 시스템 Thread Pool에 있는 Thread 정보를 알 수 있다.

참고

단, JEUS 콘솔 툴에서는 서블릿 요청 Thread와 EJB 리모트 요청 Thread만 모니터링할 수 있다.

● Thread 정보 확인

콘솔 툴에서 Thread 정보를 확인하는 방법이다.

johan>ti

Thread information for [johan_container1] container

========================================================================

servlet threads for 'http1' listener

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

| tid | name | state | elapsed | uri |

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

| 72 | http1-w00 | waiting | 9859 | |

| 73 | http1-w01 | waiting | 23828 | |

| 74 | http1-w02 | waiting | 23828 | |

| 75 | http1-w03 | waiting | 23828 | |

| 76 | http1-w04 | waiting | 23828 | |

| 77 | http1-w05 | waiting | 23828 | |

| 78 | http1-w06 | waiting | 23828 | |

| 79 | http1-w07 | active | 2265 | /examples/ClusteredEJBCall.jsp |

| 80 | http1-w08 | waiting | 23828 | |

| 81 | http1-w09 | waiting | 23828 | |

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

elsapsed: elapsed time (ms)

========================================================================

=============================================================


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

| | total | active | idle | blocked | recon |

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

| num. of threads | 10 | 1 | 9 | 0 | 0 |

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

total = active + idle, recon: reconnecting

=============================================================

==================================================================================

EJB RMI threads

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

| tid | name | state | active_time |

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

| 84 | RMI TCP Connection(1)-192.168.x.x [container1-15] | active | 2297 |

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

active_time: time after thread created (ms)

==================================================================================

===========================================

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

| | total | active | idle |

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

| num. of threads | 1 | 1 | 0 |

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

total = active + idle

===========================================

● 특정 Thread의 stack trace 조회

콘솔 툴에서 특정 Thread의 stack trace를 조회하는 방법이다. 주로 Thread 정보를 보는 명령(콘솔 툴에

서의 ti 명령)을 통해 보았을 때 블록된 Thread가 있을 경우 해당 Thread의 Stack을 확인하는 데 사용한

다.

johan>strace 79

servlet thread [tid=79] Stack trace

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(SocketInputStream.java:129)

. . .

at jeus.ejb.client.RemoteBusinessHomeClientHandler.create(RemoteBusinessHo

meClientHandler.java:76)

at jeus.ejb.client.BusinessObjectFactory.getObjectInstance(BusinessObjectF

actory.java:102)

at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304

)

. . .


at jeus.jndi.JEUSFailoverContext.lookup(JEUSFailoverContext.java:270)

at javax.naming.InitialContext.lookup(InitialContext.java:392)

at jeus_jspwork._600_ClusteredEJBCall_5fjsp._jspService(_600_ClusteredEJBC

all_5fjsp.java:67)

at jeus.servlet.jsp2.runtime.HttpJspBase.service(HttpJspBase.java:106)

. . .

at jeus.servlet.engine.HttpRequestProcessor.run(HttpRequestProcessor.java:

278)

참고

1. JEUS 콘솔 툴의 ti 명령과 strace 명령에 대한 자세한 정보는 “JEUS Reference Book”의 “4.2.3. 공

통 명령어”를 참조한다.

2. WebAdmin을 이용한 서블릿 요청 Thread와 EJB 리모트 요청 Thread 정보와 stack trace는 We

bAdmin의 "JEUS 모니터링" 의 "요청 Thread 모니터링" 에서 확인할 수 있다. JEUS WebAdmin에서

는 이 외에도 "JEUS 모니터링" 의 "Thread Pool 모니터링"에서 시스템 Thread Pool의 정보와 시스템

Thread Pool의 Thread 정보를 확인할 수 있다. 더 자세한 사항은 "JEUS WebAdmin 안내서"와 온라

인 도움말을 참조한다.

3.2.2. Thread 제어

JEUS에서는 특정 Thread에 interrupt 시그널을 보내어 수행 중인 작업을 중단할 수 있도록 Exception을

발생시키는 기능이 있다.

주의

이 기능은 현재는 실험적으로 제공되는 기능으로 Thread에 interrupt가 걸려 있으면 수행 중인 Thread

가 바로 중단되는 것이 아니라 interrupt status를 체크하여 Exception을 던져 더이상 진행하지 않도

록 유도하는 것이기 때문에 발생하는 Exception에 대해서는 사용자 애플리케이션에서 처리해야 한

다. exception을 제대로 처리하지 않아서 발생하는 문제에 대해서는 사용자에게 책임이 있다.

Thread interrupt

Thread에 interrupt를 건다는 것은 동작하고 있는 Thread에 interrupt 시그널을 보내서 현재 진행 중인 동

작의 중단을 유도하기 위해 Exception을 발생시켜 이후의 작업을 더이상 진행하지 않도록 힌트를 주는 것

이다. 주로 요청이 블록되어 있거나, 예상한 시간보다 오래 지체되어 있는 경우에 사용될 수 있다.

실제로 Thread에 interrupt가 걸린다고 해서 해당 Thread가 강제적으로 멈춘다든가, interrupt를 발생시키

는 순간에 바로 효과가 있는 것은 아니다.

JEUS에서는 서블릿 Thread, EJB 리모트 요청 Thread와 시스템 Thread Pool의 수행 중인 Thread에 interrupt

시그널을 보낼 수 있는 기능을 지원한다. 이때 Thread가 JNDI 원격 커넥션이나 EJB operation, JDBC op

eration, 또는 IO작업을 진행 중이면 interrupt가 걸릴 수 있다.


● 서블릿 Thread

서블릿 Thread는 다음의 경우들에 대해 interrupt가 걸려 있으면 Exception이 발생한다. 이때 발생하는

Exception에 대한 처리는 사용자 애플리케이션에서 해야 한다.

– JNDI 원격 커넥션을 맺으려고 할 때

– JNDI 원격 operation을 수행하려고 할 때

– EJB 호출하려고 할 때

– JDBC 커넥션을 얻어올 때 또는 커넥션 객체의 메소드를 호출할 때

jeusadmin이나 WebAdmin을 통해 관리자가 직접 interrupt를 걸 수 있으며, 서블릿 Thread의 수행시간

을 체크하여 자동으로 interrupt 되도록 하는 기능을 제공한다. 이 기능에 대한 설정 방법은 “JEUS Web

Container 안내서”의 “4.3.5. 자동 Thread Pool 관리 설정(Thread 상태 통보)”을 참고한다.

● EJB 리모트 요청 Thread

EJB operation의 경우에는 다음의 시점에 interrupt status를 체크해서 javax.ejb.EJBException을 발생

시킨다.

– EJB 2.x 방식으로 create와 같은 EJBHome 메소드를 호출할 때(EJB 3.0의 경우 사용자가 EJB lookup

을 하면 컨테이너 내부적으로 create 처리)

– EJB 비즈니스 메소드를 호출할 때

이때 발생하는 Exception에 대해서는 사용자 애플리케이션에서 적절하게 처리해 주어야 한다. 만약 EJB

비지니스 메소드 호출이 이미 들어간 상태에서 interrupt 시그널을 받았다면 Exception이 발생하지 않을

수 있다. 하지만 해당 메소드에서 다른 EJB를 call한다던가, JDBC operation이나 JNDI operation을 사

용하는 경우라면 interrupt가 걸릴 수도 있다.

● JDBC

JDBC operation의 경우에는 아래 operation을 수행하려고 할 때 interrupt 시그널을 받았다면 ja

va.sql.SQLException이 발생한다. 이때 발생하는 Exception에 대해서는 사용자 애플리케이션에서 적절

하게 처리해 주어야 한다.

– DataSource#getConnection()을 통해 Connection Pool에서 커넥션을 가져올 때

– Connection Pool에서 가져온 java.sql.Connection에 대해서 operation을 수행하려고 할 때

– JDBC Connection Pool 설정에 use-sql-trace나 stmt-caching-size 옵션을 설정하고 executeQuery와

같은 operation을 수행 하려고 할 때(옵션에 대한 자세한 설명은 “8.3.4. Connection Pool 설정” 참고)

● JNDI

JNDI operation을 수행하는 중에도 interrupt의 효과가 있는 경우가 있다. 다음의 JNDI operation을 수행

하려고 할 때 interrupt 시그널을 받았다면 javax.naming.NamingException이 발생한다. 이때 발생하는

Exception에 대해서는 사용자 애플리케이션에서 적절하게 처리해 주어야 한다.

– JNDI 원격 커넥션을 맺을 때(javax.naming.InitialContext를 생성하는 시점)

– JNDI operation을 하기 위해 원격 메시지를 보낼 때


lookup, bind, rebind, rename과 같은 JNDI operation일 경우이다. 단, 로컬(같은 JVM)에 있는 레지스

트리에 접근하거나 캐쉬에 접근하는 경우에는 interrupt의 효과가 없다.

● IO 작업

IO작업을 할 때는 항상은 아니지만 상황에 따라 interrupt의 효과가 있을 수 있다.

– java.nio.channels.SocketChannel

java.nio.channels.SocketChannel을 사용하는 경우에는 interrupt에 걸리게 된다. java.nio.channels.Sock

etChannel을 사용해서 연결할 때는 3단계로 분리된다.

첫 번째 단계인 begin단계에서는 Thread에 interrupt status가 설정되었는지 체크하고 설정되어 있다

면 채널을 종료한다. 실제 연결하는 단계에서는 interrupt status가 설정되어 있다면 connect()를 진행

하지 않고, end 단계에서 interrupt가 걸려 있다면 java.nio.channels.ClosedByInterruptedException이

발생한다(이후에 interrupt status는 clear된다).

– java.nio.channels.SocketChannel#read()/java.nio.channels.SocketChannel#write()

java.nio.channels.SocketChannel#read()나 java.nio.channels.SocketChannel#write() 하는 경우에도

역시 3단계로 나뉘게 된다.

첫 번째 단계인 begin단계에서는 interrupt status가 설정되었는지 체크하고 설정되어 있다면 채널을

종료한다. 그리고 실제 IO를 처리하는 단계에서는 interrupt status가 설정되어 있다면 실제 read, write

를 진행하지 않고, 마지막 end 단계에서는 java.nio.channels.ClosedByInterruptedException이 발생

한다(이후에 interrupt status는 clear된다).

java.nio.channels.ClosedByInterruptedException이 발생하고 난 후 이전에 만들었던 채널을 사용해

서 read, write를 하려고 하면 IO작업이 수행되지 않고 java.nio.channels.ClosedChannelException이

발생한다.

– java.net.Socket 사용

java.net.Socket을 사용할 때는 OS, JVM에 따라서 다르다. HP-UX와 Solaris에서는 JVM의 컴파일 옵

션에 따라 Socket IO작업에 interrupt를 걸 수 있다.

Socket의 스트림을 통해 read나 write를 하려고 할 때 interrupt status가 체크되기 때문에 interrupt에

걸릴 수 있고 java.net.SocketException이 발생한다(이후에 interrupt status는 clear된다). 하지만 이때

실제 소켓이 끊어지는 것은 아니고 interrupt가 걸린 시점의 다음 operation만 중단된다(다음에 read,

write operation을 수행하면 제대로 동작한다).

그 외 Windows, IBM AIX, LINUX 등에서는 Socket IO작업을 하는 Thread에 interrupt를 걸어도 효과

가 없다.

● Object#wait() / Thread#sleep() /Thread#join()

Thread가 Object#wait(), Thread#sleep() 또는 Thread#join()하고 있는 상태라면 해당 Thread는 interrupt

에 걸리게 된다. 이 경우 해당 Thread는 java.lang.InterruptedException이 발생한다(이후에 interrupt

status는 clear된다).

참고

자세한 사항은 해당 클래스의 Javadoc API 문서를 참고한다.


JEUS에서는 콘솔 툴과 WebAdmin을 통해 Thread에 interrupt 시그널을 보낼 수 있는 명령을 제공한다. 다

음은 JEUS 콘솔 툴을 사용하여 특정 Thread에 interrupt 시그널을 보내는 예제이다.

johan>interrupt-thread 79

WARNING: This function is EXPERIMENTAL yet and the status of target thread could b

e inconsistent.

Do you really want to signal the interruption hint to the thread [tid=79] in the e

ngine container [johan_container1]? (y : n):>y

Signaled the interruption hint

참고

JEUS 콘솔 툴의 interrupt-thread 명령에 대한 자세한 정보는 “JEUS Reference Book”의 “4.2.3.27.

interrupt-thread”를, WebAdmin을 통해 Thread에 interrupt를 거는 방법은 "JEUS WebAdmin 안내

서"와 온라인 도움말을 참고한다.


제4장 JEUS 클러스터링

본 장에서는 JEUS의 클러스터링의 구조 및 동작에 관해 전반적으로 설명한다.

4.1. 클러스터링 종류시스템 과부하와 장애 대책을 위해서 JEUS 여러 노드를 클러스터링으로 묶어서 운영할 수 있다. 이를

JEUS 간의 클러스터링이라고 한다.

JEUS는 여러 가지 방식의 클러스터링 기능을 제공하고 있다. 사용하려는 목적에 따라 어떤 형태의 클러

스터링이 필요한지 다를수 있으므로 사용자의 목적에 맞게 필요한 부분을 적용하도록 해야 한다.

● 노드 클러스터링

가장 기본이 되는 클러스터링으로 각 노드들은 서로 1:1로 연결을 형성하고 서로 메시지를 보내어 통신

하게 된다. 일정한 주기(기본 15초. 주기는 시스템 프로퍼티(“JEUS Reference Book”의 “1.2. 서버 시스

템 프로퍼티”)로 설정 가능)마다 상대 노드가 살아있는지 Keep-Alive 메시지를 주고받아 상태를 관리하

게 된다.

노드 클러스터링은 JNDI 클러스터링, Security 서버 클러스터링, 세션 클러스터링과 EJB 클러스터링을

위한 기본 요건이다. JNDI 클러스터링과 Security 서버 클러스터링은 JEUS Manager가 클러스터링을

형성할 때 자동으로 형성되므로 별다른 설정은 필요없지만 웹 서버와 세션, EJB 클러스터링은 특별한

설정이 필요하다.

● JNDI 클러스터링

Naming 서버들 간의 Binding 객체들을 공유하기 위해 사용된다. 즉, A,B,C 클러스터링 환경에서 A에서

bind한 객체는 B,C에서도 lookup이 가능하고 A가 다운이 되어도 B,C에서는 여전히 A에서 bind한 객체

를 lookup할 수 있다. 자세한 내용은 “제6장 JNDI Naming Server”를 참조한다.

● Security 도메인 클러스터링

기본적으로 도메인별 보안 서비스를 적용하기 위해서 도메인 클러스터링을 지원한다. 자세한 내용은

“JEUS Security 안내서”의 “제1장 보안 시스템의 소개”를 참조한다.

● 웹 서버 클러스터링

웹 서버와 서블릿 엔진으로 구성된다. 시스템의 HTTP 처리의 성능 향상을 위해서 사용한다. 자세한 내

용은 “JEUS Web Container 안내서”의 “제4장 웹 서버 연결과 클러스터링”을 참조한다.

● 세션 클러스터링

서블릿의 세션 데이터의 분산 처리와 EJB Stateful Session Bean의 fail-over를 위해서 사용된다. 세션

클러스터링에는 중앙 집중 세션 서버와 분산 세션 서버의 방식이 있다. 자세한 내용은 “제10장 세션 서

버”를 참조한다.

● EJB 클러스터링

제4장 JEUS 클러스터링 45

EJB 엔진과 Bena의 백업 및 부하 분산을 위해서 사용한다. 자세한 내용은 “JEUS EJB 안내서”의 “제6

장 EJB 클러스터링”을 참조한다.

각각의 클러스터링 종류에 대한 자세한 방식은 각 부분을 참조하도록 하고 여기서는 노드 클러스터링의

부하 분산(Load Balancing)과 Fail-Over에 대해서 설명한다.

4.2. 노드 클러스터링시스템 과부하와 장애 대책을 위해서 JEUS 여러 노드를 클러스터링으로 묶어서 운영할 수 있다. 이를

JEUS 간의 클러스터링이라고 한다.

클러스터링에 속하는 모든 노드의 정보는 각 노드의 JEUSMain.xml 파일에 담겨 있게 된다. 그래서 각 노

드는 자신의 JEUSMain.xml 설정을 이용해서 클러스터링 내의 모든 노드를 구별하게 된다.

[그림 4.1] 3개의 노드와 설정 파일(JEUSMain.xml)을 포함한 JEUS 클러스터링

Node A

Node B

Node C

JEUSMain.

xml

<node A>

<node B>

<node C>

JEUSMain.

xml

<node A>

<node B>

<node C>

JEUSMain.

xml

<node A>

<node B>

<node C>

위의 그림에서 노드 A, B, C의 JEUSMain.xml 파일 3개는 거의 유사하다. 설정에서 <node> 태그가 100%

동일할 필요는 없으나, 동일하게 사용하는 것을 권장한다. 실제 중요한 것은 클러스터 내의 노드가 모두

JEUSMain.xml에 포함되어 있어야 한다는 것이다. 그리고, 타 노드의 정보는 노드의 이름 정도만 포함시

켜도 무방하다. 예를 들면, A노드의 JEUSMain.xml에 B노드의 모든 정보를 포함시킬 필요는 없고 단지 B

노드의 <node>/<name> 태그까지의 정보만 포함시키면 가능하다.

그러면, 각 노드는 자신이 사용할 노드가 셋 중 어떤 것인지 어떻게 알아내는가? 바로 hostname(표준 Java

API 를 사용해서)을 얻고 JEUSMain.xml 에서 설정된 노드명을 비교함으로써 결정된다. 노드명이 hostname

과 일치하는 노드의 설정을 사용하게 된다.

예를 들어, 노드가 호스트 “A”에서 동작을 시작할 경우, 노드 “A”의 설정을 사용한다. 다른 2개 노드의 설정

정보는 클러스터링을 형성하는 다른 노드에서 사용한다. 만약 가상 호스트(Virtual Host)를 사용하는 경우

에는 hostname과 base port를 가지고 JEUS_HOME\config\vhost.properties에서 실제 호스트 이름을 찾아


서 노드명과 비교함으로써 자신의 노드를 찾을 수 있다. 가상 호스트에 대한 설명은 “1.2.1. 가상 노드”를

참조하고 설정에 대해서는 “2.2.2. 가상 노드 설정”을 참조한다.

4.2.1. 노드 클러스터링 형성

JEUS 노드 간에 클러스터를 구성할 때 JEUS는 다음과 같은 방식으로 노드 간에 연결을 구성한다.

1. 각 JEUS Manager는 설정 파일(JEUSMain.xml)에서 자신의 노드 이외의 노드와 연결을 시도한다.

2. 만약 노드 하나가 죽은(dead)것으로 확인되면(JEUS Manager 간의 연결이 되지 않았거나 끊어졌을 때)

강제로 클러스터링에서 제외된다. 그래서 “dead” 노드는 클러스터가 형성될 때 무시하고 넘어가게 된

다. 자세한 내용은 "노드 클러스터링을 형성한 노드에 장애가 발생할 경우"를 참고한다.

3. JEUS Manager가 이전에 죽은(dead) 노드와 제외된 노드가 다시 살았는지(alive)를 확인하고, 살았다

면 클러스터링에 포함한다.

노드 클러스터링을 형성한 노드에 장애가 발생할 경우JEUS 클러스터링 상태에서 장애는 OS 레벨 에러나 네트워크 단절 등, 다양한 원인으로 발생될 수 있다.

다음 그림에서 노드 B는 에러로 장애가 발생한다.

[그림 4.2] 노드 클러스터링 장애

Node A

Node B

Node C

JEUSMain.

xml

<node A>

<node B>

<node C>

JEUSMain.

xml

<node A>

<node B>

<node C>

2.check

if alive

every 15

seconds

2.check

if alive

every 15

seconds

1.Node B

fails

그림에서 노드 B가 장애가 발생했을 때, 노드 A와 C는 그것을 감지하고 노드 B가 다시 살아나는지 여부를

일정한 주기로 Keep-Alive 메시지를 보내서 계속 확인한다. 이 Keep-Alive check는 기본이 15초마다 수행

되고 시스템 프로퍼티(“JEUS Reference Book”의 “1.2. 서버 시스템 프로퍼티”)로 설정 가능하다. 만약 노

드 B가 살아나면, 노드 A와 C는 Keep-Alive check를 통하여 감지해 낸다. 그리고 클러스터링은 이전의 형

태를 복구해서 [그림 4.1]로 되돌아간다.


위와 같이 각 노드는 자신의 위치에서 다른 노드들의 이상 여부를 check해서 클러스터링 정보를 유지한

다. 해당 정보는 jeusadmin의 ‘nodelist’ 명령으로 확인할 수 있다.

4.2.2. 노드 클러스터링 상태 전이

노드 클러스터링의 경우 Target 노드에 대해 다음과 같은 3가지의 상태를 가지고 있다.

다음은 상태전이에 대한 그림이다.

[그림 4.3] 클러스터링의 상태전이

설명상태

노드 클러스터링의 커넥션 연결이 정상 종료된 상황 또는 초기치의 상태이다.

예) Target 노드의 정상 다운

INACTIVE

노드 클러스터링의 커넥션 연결이 정상적인 상황이다.

예) Target 노드의 정상 운영 상태

RUNNING

노드 클러스터링의 커넥션 연결이 비정상 종료된 상황이다.

예) Target 노드의 비정상 다운. 장애 또는 kill -9등으로 다운 된 상황

FAILED

RUNNING 상태에서 INACTIVE 또는 FAILED 상태로 변경이 가능하며, 반대로 INACTIVE 또는 FAILED

상태에서 RUNNING 상태로의 변경도 가능하다. 하지만 INACTIVE 상태에서 FAILED 상태로 또는 FAILED

상태에서 INACTIVE 상태로의 변경은 불가능하다.

INACTIVE, FAILED의 상태일 경우 노드 클러스터링에서 제외되며, 차후 주기적인 모니터링 기능을 통해

재연결이 가능하다.

4.2.3. 노드 클러스터링 동적 노드 추가

일반적인 클러스터링 방법은 각 노드에 클러스터링을 구성하는 노드의 정보를 각 노드가 가지고 있는 것

으로 정적 클러스터링 구성이라고 한다.


반면에 JEUS 노드를 동적으로 추가해야 할 경우가 있다. 즉, 별개로 설정된 JEUS 노드가 동작중인 JEUS

클러스터에 추가될 수 있다. 이를 위해서는 동적으로 추가하고 싶은 노드에만 클러스터링에 포함되는 노

드의 정보를 모두 설정하고 실행시키면 각 노드에 동적으로 기동된 노드가 연결을 시도한다.

다음의 그림은 이러한 작업을 보여준다. 그림(2번째 지점)에서 보듯, 새 노드에서 JEUS를 실행하면, 클러

스터링의 다른 노드에서 새 노드의 존재와 설정에 대해서 알지 못하더라도 “JOIN” 시도가 진행된다.

[그림 4.4] JEUS 클러스터에 새로운 JEUS 노드(D)의 동적 추가

Node A

Node B

Node C

JEUSMain.

xml

<node A>

<node B>

<node C>

JEUSMain.

xml

<node A>

<node B>

<node C>

JEUSMain.

xml

<node A>

<node B>

<node C>

Node DJEUSMain.

xml

<node A>

<node B>

<node C>

<node D>

1. Node D is

dynamically booted.

2. Node D tries to

join the cluster by

contacting node C.

Runtime list

of nodes in

the cluster:

A

B

C

D

그 결과 D는 A, B, C 노드에게 접속을 시도해서 A, B, C에게 자신의 존재를 알린다. 결국 A, B, C, D는 모

두 서로를 체크하면서 클러스터링을 이룬다.

참고

동적으로 D 노드가 추가 되더라도 A ,B, C 노드의 JEUSMain.xml에 D 노드를 추가해 주지 않는다.

따라서 A, B, C, D 노드를 모두 재시작할 때 A, B, C, D 노드가 정적으로 클러스터링을 형성하지 않

는다.


4.2.4. 백업 노드

노드 클러스터링은 클러스터링에 참여하는 모든 노드가 동등한 입장으로 부하 분산을 수행하는 것과 달

리, 주 노드와 백업 노드 방식은 2개의 노드가 있을 때 다른 한 노드를 Fail-Over를 위한 백업 노드로 사용

하고자 할 때 이용할 수 있다.

백업 노드는 자신이 백업해야 하는 노드(주 노드)가 다운이 되었을 경우에만 그 노드를 대신하여 Fail-Over

작업을 수행한다. 주 노드가 종료(Down)되었을 때 백업 노드는 자동으로 기동되어 다운된 노드의 설정 데

이터를 읽고 그 설정에 따라 엔진 컨테이너를 부팅하여 서비스가 계속 유지되도록 한다. 백업 노드는 또한

서비스 수행하면서 주 노드가 살아 났는지 일정한 주기로 확인을 하고 주 노드가 살아나면 백업 노드는 주

노드의 Fail-Over 작업 수행 전의 상태로 돌아간다.

백업 노드는 주 노드가 다운되었을 경우에만 주 노드의 서비스를 대신해주기 때문에 주 노드가 정상 동작

하는 경우에는 백업 노드는 아무 일도 수행하지 않는다. 따라서, 백업 노드가 있는 머신은 평소에는 다른

용도로 사용되다가 주 노드가 정상적이지 않을 경우에만 백업을 수행하고자 하는 경우에 유용하게 사용

될 수 있다.

참고

주 노드의 종료(Down)라 함은 주 노드의 비정상종료(FAILED) 상태를 의미하며, 기본적으로 주 노드

가 정상종료(INACTIVE) 된 경우 백업 노드는 아무 동작을 하지 않는다. 즉, 주 노드의 상태가 RUNNING

-> FAILED로 변경되는 상황에서 백업 노드는 주 노드를 대신하여 서비스를 수행한다.

단, 주 노드가 백업 노드를 기동(Booting)하도록 하는 옵션을 주고 정상종료(INACTIVE)한 경우 백업

노드는 서비스를 수행한다. 즉, RUNNING -> INACTIVE 로 변경되는 상황이더라도 백업 노드는 주

노드를 대신하여 서비스를 수행한다. 이 옵션에 대한 자세한 설명은 “JEUS Reference Book”의 “4.2.3.

공통 명령어”를 참조한다.

백업 노드에 대한 설정에서 주의할 점은 A의 백업 노드가 B이면 A의 노드 설정에 B를 자신의 백업노드로

설정 하는 것이 아니라 B노드에 B가 백업할 대상의 노드가 A임을 설정한다는 것이다. 좀 더 자세한 설정

은 “4.3.2. 백업 노드 설정”을 참조한다.

4.3. 노드 클러스터링 설정

4.3.1. 노드 클러스터링 설정

JEUS 클러스터링은 서로 다른 노드 간의 클러스터링이므로 네트워크 관련 설정이 정확하게 이뤄져야 하

고 하나의 노드는 다른 노드에 대해서 정확하게 알아야 하므로 설정할 때 다음의 3가지를 주의한다.

● 각 머신의 호스트 파일에, 클러스터링되는 머신의 hostname과 IP 주소를 정확히 매핑해야 한다.

hostname과 IP 주소는 UNIX의 경우 /etc/hosts 파일에서 매핑하고, Windows의 경우에는 %System

Root%\system32\drivers\etc\hosts 파일에서 매핑한다.

● 가상 노드를 사용하는 노드가 있다면, 클러스터링에 참여하는 모든 머신의 vhost.properties에 가상 노

드를 사용하는 노드의 실제 hostname을 설정해 놓아야 한다.


가상 노드를 사용하도록 설정(jeus.vhost.enabled값을 true로 설정)하며, 각 머신의 vhost.properties에

모든 머신의 정보를 입력(즉, 각 가상 노드의 이름과 BASEPORT의 값을 입력)한다. 만약, 가상 노드를

사용하지 않는다면, 모든 머신이 가상 노드를 사용하지 않도록 설정(jeus.vhost.enabled값을 false로 설

정)하며, 각 머신의 JEUS_BASEPORT를 동일하게 설정한다.

● JEUS의 관리자 ID와 패스워드를 모든 노드에 동일하게 적용한다.

이제 JEUSMain.xml에서 어떻게 설정되는지 예제를 통해 설명한다. WebAdmin을 이용하면 쉽게 설정할

수 있으나 본 절에서는 직접 XML에 설정하는 방법을 설명한다.

클러스터링을 만들기 위해서는 클러스터링에 참여하는 각 노드의 JEUSMain.xml을 수정해야 한다. 각

JEUSMain.xml 파일에는 반드시 클러스터링에 참여하는 노드들의 <node>에 설정되어야 한다.

[예 4.1] 노드 클러스터링의 설정 1 : <<JEUSMain.xml>>

<jeus-system>

<node>

<name>

A

</name>

. . . <!—노드의 다른 설정부분 -->

</node>

<node>

<name>

B

</name>

. . . <!—노드의 다른 설정부분 -->

</node>

<node>

<name>

C

</name>

. . . <!—노드의 다른 설정부분 -->

</node>

. . . <!—Manage의 다른 설정부분, -->

</jeus-system>

위의 예에서 3개의 노드 A, B, C는 클러스터링의 각 JEUSMain.xml 파일에서 설정되어 있다. 위 예제처럼

클러스터링에 참여하는 모든 노드의 설정을 해도 되지만 다음의 예제처럼 각 노드에 포함되는 JEUSMain.xml

에 자기 노드에 대한 자세한 설정과 클러스터링에 참여하는 <node>/<name> 태그만 설정해도 무방하다.

[예 4.2] 노드 클러스터링의 설정 2 : << JEUSMain.xml>>

<jeus-system>

<node>

<name>


A

</name>

. . . <!—노드의 다른 설정부분 -->

</node>

<node>

<name>

B

</name>

</node>

<node>

<name>

C

</name>

</node>

. . . <!—Manager의 다른 설정부분, -->

</jeus-system>

위의 클러스터링 예에 동적으로 D 노드를 추가하는 작업은 D 노드의 JEUSMain.xml에 D 노드의 설정과

A,B,C 노드의 이름을 추가한다. 그리고 D 노드를 기동(boot)하면 현재 동작 중인 클러스터에(A,B,C 노드)

동적으로 새로운 노드(D 노드)가 추가된다.

4.3.2. 백업 노드 설정

위에서 설명 했듯이 <backup-node>를 주 노드가 아닌 백업 노드에 설정해야 함을 주의해야 한다. 예를 들

어 A의 노드가 주 노드이고 B노드가 백업 노드이면 B노드의 JEUSMain.xml에 <backup-node>로 A노드를

추가하고 A노드의 JEUSMain.xml에는 B에 대한 설정을 하지 않는다.

또한 주 노드, 백업 노드의 기능을 사용하기 위해서는 서로 간의 노드 클러스터링 설정이 먼저 되어 있어

야 한다.

[예 4.3] 백업 노드 설정 1 : << JEUSMain.xml>>

<jeus-system>

<node>

<name>A</name>

. . . <!—노드의 다른 설정부분 -->

</node>


</jeus-system>

[예 4.4] 백업 노드 설정 2 : << JEUSMain.xml>>

<jeus-system>

<node>

<name>B</name>

<backup-node>A</backup-node>


. . . <!—노드의 다른 설정부분 -->

</node>


</jeus-system>

4.4. 노드 클러스터링 컨트롤클러스터는 다음의 과정으로 컨트롤할 수 있다.

1. 클러스터를 시작하기 위해서는 먼저 ‘jeus’ 명령으로 각 JEUS들을 시작한다.

2. jeusadmin 콘솔 툴 또는 WebAdmin을 열어서 각각의 JEUS Manager에 boot 명령을 내린다. 기동 순서

는 상관 없다.

3. 클러스터링을 종료하려면, 클러스터링의 각 노드에 down 명령을 실행하여 shutdown시킨다. 완전히 클

러스터링을 종료하려면 'jeusexit' 명령을 사용한다.

참고

jeusadmin 콘솔 툴에 관한 자세한 설명은 “JEUS Reference Book”의 “4.2.3. 공통 명령어”를 참조한

다.


제5장 Security 관리

본 장에서는 기본적으로 JEUS 서버를 사용하는 데 있어서 필요한 암호화된 패스워드 및 계정 관리 등 몇

가지 보안 방식에 대해서 간단하게 설명한다.

참고

JEUS Security에 대한 자세한 내용은 "JEUS Security 안내서"를 참고한다.

5.1. 암호화된 패스워드 설정 방법JEUS 설정 파일에 기록해야 하는 패스워드값에 대해 암호화를 지원한다.

예를 들어, 데이터베이스 패스워드, accounts.xml 계정들의 패스워드의 경우 일반 문자열 대신 암호화된

문자열로 적을 수 있도록 하는 것이다. 암호화된 문자열로 설정하는 방법은 {알고리즘}암호문 형식으로

패스워드가 필요한 곳에 설정하면 된다.

이러한 암호화된 문자열을 사용하기 위해서는 JEUS가 제공하는 암호화 툴(Encryption Tool)을 사용해야

한다. 암호화 툴은 암호화될 대상이 되는 문자열과 알고리즘을 입력받아 결과물인 암호문을 출력하는데,

그 암호문을 위에서 언급한 형식에 맞춰서 기록한다.

참고

암호화 툴의 사용법에 관한 자세한 사항은 “JEUS Reference Book”의 “4.6. encryption”을 참고한다.

base64 또는 Hash Algorism(sha 등)은 평문이 정해지면 결과값도 항상 똑같게 나오게 되지만, 그 외의 알

고리즘들은 수행하기 위한 비밀 키(secret key)가 필요하다. 이러한 비밀 키 관리 방법에 관한 자세한 사항

은 “5.2. 비밀 키 파일 관리”를 참고한다.

다음은 암호화된 문자열을 패스워드로 설정하는 예제이다.

[예 5.1] 암호화된 문자열 패스워드 설정 : <<accounts.xml>>

<accounts xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

<users>

<user>

<name>administrator</name>

<password>{base64}amV1czEyMw==</password>

</user>

<user>

<name>javajoe</name>

<password>{AES}i06wYRz3Gqun2sKtXHIq+Tw3vUcc=</password>

제5장 Security 관리 55

</user>

. . .

</users>

. . .

</accounts>

[예 5.2] 암호화된 문자열 패스워드 설정 : <<JEUSMain.xml>>

<jeus-system xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

. . .

<resource>

<data-source>

<database>

<export-name>datasource1</export-name>

. . .

<user>scott</user>

<password>{DES}Yz3GTtzH+Tw3vR60i=</password>

. . .

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>

[예 5.3] 암호화된 문자열 패스워드 설정 : <<WEBMain.xml>>

<web-container xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

. . .

<context-group>

. . .

<webserver-connection>

<http-listener>

<port>8089</port>

. . .

<thread-pool>

. . .

</thread-pool>

. . .

<ssl-config>

<enable-secure>true</enable-secure>

. . .

<keystore-pass>

{desede}Cb7TML6654mUvOhBh9MzVDnW8ZE

</keystore-pass>

<keystore-keypassword>


</keystore-keypassword>


. . .

<truststore-pass>


</truststore-pass>

. . .

</ssl-config>

</http-listener>

. . .

</webserver-connection>

. . .

</context-group>

. . .

</web-container>

5.2. 비밀 키 파일 관리

5.2.1. 파일의 생성과 관리

암호화 툴(Encryption Tool)에서 제공하는 AES, DES, DESede, SEED, BlowFish 등의 알고리즘은 암호화,

복호화를 수행하기 위해 비밀 키가 필요하다. 이를 위해서 JEUS는 비밀 키 파일을 사용한다. 비밀 키 파

일은 암호화 툴을 처음으로 사용할 때 자동으로 생성되며, 그 이후로는 계속 그 파일을 사용한다.

비밀 키 파일은 기본적으로 JEUS_HOME/config/<node>/security의 security.key 파일이다. 또는

jeus.security.keypath 시스템 프로퍼티로 지정할 수 있다. 이 경로는 절대 경로, 상대 경로 모두 가능하며,

상대 경로의 기준 경로는 JVM을 실행한 경로이다. 경로를 디렉터리로 지정할 경우 해당 디렉터리의 secu

rity.key 파일을 이용하며, 파일로 지정할 경우에는 지정된 파일을 사용한다.

5.2.2. 파일 보호 옵션과 JEUS 기동 방법

JEUS에서는 위에서 언급한 비밀 키 파일 자체를 보호하는 옵션도 제공한다. 이를 위해서는 비밀 키 파일

을 암호화하기 위한 패스워드가 필요하다. 이를 마스터 패스워드(master password)라고 한다. 이 마스터

패스워드를 이용해서 비밀 키 파일을 보호하는 방법은 암호화 툴을 실행할 때 -protectkey 옵션을 입력한

다. 그리고 비밀 키 파일을 보호하는 옵션을 사용하면 JEUS를 기동할 때 반드시 마스터 패스워드가 필요

하다.

마스터 패스워드를 입력하는 방법은 크게 2가지가 있다.

● JEUS를 백그라운드 프로세스로 띄울 경우 시스템 프로퍼티 jeus.security.master로 지정하는 방법

● JEUS를 포그라운드(foreground) 프로세스로 띄울 경우 [-protectkey] 옵션을 명시하고 콘솔로 입력받는

방법

jeus.security.master로 지정하는 방법은 셸 스크립트에 마스터 패스워드는 입력해야 하므로 보안상 안전

하지 않다. 만약 마스터 패스워드를 사용해야 하는 상황이라면 되도록 후자의 방법을 추천한다. 백그라운


드 프로세스는 콘솔 입력을 받을 수 없기 때문에 백그라운드 프로세스로 띄우면서 [-protectkey] 옵션을 사

용할 수 없다.

참고

1. JEUS 기동에 관한 사항은 “JEUS Reference Book”의 “3.1. 사용법”을 참고한다.

2. 비밀 키에 관한 자세한 사항은 “JEUS Reference Book”의 “4.6. encryption”을 참고한다.

5.3. keystore/truststore 관리본 절에서는 SSL 통신에 사용되는 keystore 및 truststore에 관리에 관해 간단히 설명한다.

본질적으로 keystore와 truststore는 모두 Java Key Store(JKS) 형식으로 동일하다. 다만 개인키(private

key)들만 따로 모아서 만든 저장소를 keystore, 공개키(public key)들만 따로 모아서 만든 저장소를 trust

store라고 한다.

이 저장소들은 JDK에서 제공하는 keytool을 이용하여 생성 및 관리할 수 있으며, keystore, truststore 및

SSL에 대해 더 많은 정보를 원한다면 Java SE 문서나 java.sun.com에서 JSSE, JKS, keytool 관련된 정보

를 찾아볼 수 있다.

JEUS는 기본적으로 JEUS_HOME\config\<node>\keystore 파일, JEUS_HOME\config\<node>\truststore

파일을 각각 keystore, truststore로 지정해서 사용하며, keystore, truststore가 다른 경로에 혹은 다른 이름

으로 존재한다면 이를 직접 설정해 주어야 한다. 설정 방법은 시스템 전체적으로 시스템 프로퍼티로 설정

할 수도 있고, keystore, truststore가 필요한 부분에서 각각 설정할 수도 있다. 각각 설정하는 방법은 안내

서의 각 파트에 따로 설명이 되어 있다.

사용하는 시스템 프로퍼티는 다음과 같다.

설명시스템 프로퍼티

SSL에서 사용하는 keystore 파일 경로를 설정한다.jeus.ssl.keystore

(기본값: JEUS_HOME\config\<node>\keystore)

SSL에서 사용하는 truststore 파일 경로를 설정한다.jeus.ssl.truststore

(기본값: JEUS_HOME\config\<node>\truststore)

SSL에서 사용하는 keystore 패스워드를 설정한다.jeus.ssl.keypass

(기본값: jeuskeypass)

SSL에서 사용하는 truststore 패스워드를 설정한다.jeus.ssl.trustpass

(기본값: jeustrustpass)

keystore, truststore를 사용하기 위해서는 패스워드가 필요하며 따라서 위처럼 JEUS는 keystore와 truststore

의 패스워드를 설정할 수 있다. 경로와 마찬가지로 시스템 프로퍼티로 전체적으로 설정하거나 필요한 부

분에서 각각 설정할 수도 있다. 특히 keystore는 저장소 자체의 패스워드 외에 keystore 내에 존재하는 키

별로 각각 패스워드가 요구된다. 하지만 대부분의 경우에 이 패스워드들이 keystore의 패스워드와 동일하

기 때문에 JEUS 내부적으로 keystore 패스워드와 같게 사용된다.


keystore의 키 패스워드를 저장소 패스워드와 구분해야 될 경우에는 각 설정에 keystore keypassword 지

정하는 태그가 있으므로 이를 지정하여 사용한다. 그리고 keystore 내의 키들의 패스워드가 서로 다를 경

우 해당 keystore를 이용할 수 없으며 동일 keystore 내부의 키들은 모두 같은 패스워드로 설정되어 있어

야 한다.

주의

JEUS를 설치할 때 기본적으로 keystore/truststore가 포함되어 있지만, 사이트에서는 사이트용 key

store/truststore를 새로 만들어 설정하는 게 좋다.

5.4. 계정 관리 방법JEUS는 도메인별로 계정을 관리하게 되는데, 계정 저장소로 XML 저장소를 사용할 경우 다음의 경로에

계정을 설정해야 한다.

JEUS_HOME\config\<node>\security\<domain>\accounts.xml

다른 저장소를 사용하더라도 계정을 관리하는 기본적인 구조는 비슷한 경우가 많으므로 여기서는 XML을

설정하는 경우만 설명한다. JEUS에서 계정은 개인 단위인 사용자(이하 user)와 개인들의 집합인 그룹(이

하 group)으로 관리된다. 따라서, accounts.xml에서 설정할 수 있는 태그는 크게 <users>와 <groups> 2

가지로 나누어진다.

다음 예제는 계정을 설정하는 예제이며, <user> 태그의 <name>, <password>만이 필수 태그이며, 나머지

는 옵션이다.

[예 5.4] <<accounts.xml>>

<accounts xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

<users>

<user>

<description>server administrator's account</description>

<name>system</name>

<password>{base64}amV1czEyMw==</password>

<group>administrators</group>

</user>

<user>

<description>application manager's account</description>

<name>manager</name>

<password>{aes}M94siKqwZNWKZd6N7W/UXjFnuQ=</password>

<group>administrators</group>

</user>

<user>

<name>steve</name>

<password>{aes}9k44ZY4pV8Z+/4Zl1bBtVT7CYgVndAhU=</password>

<group>developer</group>

</user>

<user>


<name>alice</name>

<password>{seed}JAfE5sTFRhqQemf9rJJ++yE=</password>


</user>

<user>

<name>smith</name>

<password>{seed}jHfxZ5TxUkhFT41Len29Qy+37nCgnNU=</password>


</user>

. . .

</users>

<groups>

<group>

<description>collection of administrators</description>

<name>administrators</name>

<group>

<description>Research Center</description>

<name>research</name>

<subgroup>developer</subgroup>

</group>

<group>

<description>Develeoper group</description>

<name>developer</name>

</group>

. . .

</groups>

</accounts>


● <users>

– 태그 내에는 여러 개의 <user> 태그를 설정할 수 있다.

– 각각의 <user>는 다음의 태그들을 가진다.

설명태그

사용자에 대한 설명을 기술한다.<description>

사용자의 이름으로 도메인 내에서 그룹 이름까지 포함하여 유일해야 한다.<name>

사용자의 패스워드를 설정한다.<password>

사용자가 속하는 그룹을 설정한다.<group>

● <groups>

– 태그 내에는 여러 개의 <group> 태그를 설정할 수 있다.

– 각각의 <group>은 다음의 태그들을 가진다.


설명태그

그룹에 대한 설명을 기술한다.<description>

그룹의 이름으로 도메인 내에서 사용자 이름까지 포함하여 유일해야 한다.<name>

자신의 하위 그룹을 정의한다. <group> 태그로 정의한 그룹만 정의할 수 있다.<subgroup>

JEUS의 권한 부여 모델은 역할(이하 role)이 리소스(이하 resource)들에 대한 권한을 가지고, user를 role

에 지정하여 role이 가진 권한을 결국 role에 지정된 user가 가지게 되는 구조이다. user를 role에 지정하기

위해서는 user의 name을 role에 바로 지정할 수도 있고 user가 속한 group의 name을 role에 지정할 수도

있고, user가 속한 group의 상위 group의 name에 role을 지정할 수도 있다. 따라서, 계정의 구조가 user,

group, subgroup 등의 계층을 가지고 있는 것은 JEUS에서 비슷한 역할을 하는 user를 한 번에 비슷한 권

한을 부여하는 것이 가능하게 하기 위함이다.


제6장 JNDI Naming Server

본 장은 JEUS JNDI의 기본적인 개념과 용어, 그리고 환경 설정 방법 및 애플리케이션을 개발 방법에 대해

서 설명한다.

6.1. 개요Java Naming and Directory Interface™ (JNDI)는 Java 애플리케이션이 네트워크에서 객체를 찾고 가져올

수 있도록 하는 표준 API이다. 애플리케이션은 객체의 논리적인 이름을 통해 해당하는 객체를 찾아서 사

용할 수 있다. 사용자의 관점에서 볼 때는 이전의 엔터프라이즈 환경보다 쉽게 객체를 찾아서 사용할 수

있는 환경을 제공해준다.

JEUS JNDI는 JNDI 1.2 API와 호환되며, Sun Microsystems에서 제안한 표준 JNDI API를 지원한다. 그리

고 엔터프라이즈 환경에 적합하도록 JNDI Service Provider Interface(SPI)도 제공한다. 즉, JNDI SPI를 구

현한 제품은 JEUS JNDI 트리의 객체를 사용할 수 있다.

JEUS JNDI 서비스는 JEUS 시스템 전반적으로 사용되므로, EJB, 서블릿/JSP, JMS, JDBC 등을 사용할

때마다 보게 될 것이다.

6.2. 기본 개념과 구조JEUS JNDI는 객체를 bind하고 lookup하는 고유의 아키텍처를 가지고 있다. 우선 JEUS JNDI의 구조와

기본 개념에 대해서 설명한다.

6.2.1. 기본 개념

JEUS Manager를 시작하면 JEUS는 자동적으로 JNDI 서비스를 준비한다. JNDI 서비스는 JNDI Naming

Server가 제공하는데, 이것이 실행될 때 내부적으로 JNS Naming Server(이하 JNSServer)가 실행된다.

이 JNSServer와 통신하기 위한 클라이언트 역할을 하는 것이 JNSLocal Naming Client(이하 JNSLocal)이

다.

JNSLocal은 JNSServer와 접속되어 있어, 객체의 bind와 lookup은 JNSLocal에서 먼저하고, 다음으로

JNSServer에서 진행된다. 하나의 JNSServer는 하나 이상의 JNSLocal과 접속되어 있으며, 또한

JNSServer들도 다른 JNSServer와 접속하고 있어(특히 클러스터링 환경일 때) 트리와 같은 구조를 이루

고 있다. 이 구조를 JNDI 트리라고 한다.

JNDI 트리는 객체를 bind하거나 lookup할 때 사용되는데, 모든 객체는 서버들을 통해서 JNDI 트리로 bind

되고 lookup된다. 애플리케이션에서 JNSLocal로 객체의 bind을 요청하면 JNDI 트리로 전달되어 bind되

며, 이렇게 bind된 객체는 각 JNSLocal을 통해 애플리케이션에서 lookup할 수 있다.

제6장 JNDI Naming Server 63

JNDI 트리의 객체를 액세스할 때는 InitialContext를 통해서만 가능하다. 그러므로 애플리케이션에서

JNDI를 사용하려면 반드시 InitialContext 객체를 생성해야만 한다. 이 객체는 JNDI 트리에 접근해서 객체

를 핸들링할 수 있도록 해준다. 그리고 객체를 bind하거나 lookup할 뿐만 아니라, 객체의 목록을 가져올

수 있으며 제거할 수 있는 기능을 한다.

6.2.2. JNDI Naming Server 아키텍처

본 절에서는 JNDI 트리 구조가 실제로 어떻게 작동되는지 자세히 설명한다.

JNDI 트리는 JNSServer와 JNSLocal로 구성되어 있다. JNSServer는 JEUS Manager의 JVM에 존재하며,

JNSLocal은 각 엔진 컨테이너 또는 클라이언트의 JVM에 존재한다. JNSServer는 JEUS JNDI 아키텍처의

메인으로 JNDI 트리를 생성하고 관리한다. JNSServer는 그 하위에 JNSLocal을 둬서 관리한다.

다음 그림은 JNSServer와 JNSLocal의 관계를 나타낸다.

[그림 6.1] JNSServer와 JNSLocal의 관계

JNS Server

JNS Local JNS Local

JNDI SPI JNDI SPI

JNDI API JNDI API

Clients Clients

전체 JNDI 트리를 액세스하기 위해서는 JNSLocal이 JNSServer로 요청을 보내게 된다. 그리고 JNSServer

는 다른 노드의 JNSServer와 연결되어서 클러스터링을 구성한다. JNSLocal은 JNSServer와 노드 내에서

상호 작용을 하며, 클라이언트의 액세스 요청을 처리한다. 클라이언트는 JNSServer로 바로 접근하는 것

이 아니라 JNSLocal을 통해서 객체를 bind하고 lookup한다.

JNSServerJNSServer는 JNDI 트리를 관리하며, JNSLocal이 JNDI 트리를 액세스할 수 있도록 하는 독립적인 Naming

Server이다. JNDI 트리를 확장하기 위해서 여러 개의 JNSServer를 연결할 수 있다. JNSServer는 다른 노

드의 JNSServer와 직접적으로 연결할 수 있기 때문이다. JEUS에서는 JEUS Manager가 시작되면

JNSServer는 자동적으로 JNSLocal의 접속을 기다린다.

JNSLocal

JNSLocal의 기본적인 기능은 JNSServer로 접속하여 애플리케이션의 요청을 전송하고 JNSServer의 결

과를 다시 돌려주는 것이다. 각 JVM에서는 하나의 JNSLocal 싱글턴 인스턴스가 존재한다. 그래서 lookup


을 처리할 때 하나의 서버만 사용하면 되므로, 엔터프라이즈 환경에서 EJB와 서블릿을 사용할 때 효과적

이다.

다음은 JNSLocal의 중요 기능이다.

● JNDI 트리 접속

JNSLocal은 JNSServer에 접속해서, JEUS Manager가 관리하는 JNDI 트리로 접속하는 방법을 제공한

다. bind되고 lookup되는 객체는 전체 JNDI 트리에서 공유되거나, 클라이언트의 설정에 따라서 특정 클

라이언트만 액세스할 수도 있다.

● lookup된 객체의 캐싱

JNSLocal은 자주 사용되는 객체를 캐싱해서, 클라이언트가 더 빠르게 사용할 수 있도록 한다. JNSLocal

은 JNSServer와 통신을 하면서 객체를 캐싱(caching)한다.

● JNSServer와의 연결 관리

JNSLocal은 클라이언트의 요청을 받아서 JNSServer로 전달하고, 그 결과를 받아서 리턴한다. 클라이

언트가 있는 JVM에 JNSLocal이 존재하므로 별다른 I/O 없이 효율적으로 통신할 수 있다.

JNSLocal에는 JNSServer의 위치(같은 노드인지 아니면 원격지에 있는지)에 따라서 2가지 종류로 나뉜다.

설명구분

엔진 컨테이너의 엔진들의 EJB Bean과 서블릿, JSP가 사용하는 모듈이다.Server-side JNSLocal

Server-side JNSLocal을 사용하려면 java.naming.factory.initial 프로퍼티 값

을 jeus.jndi.JNSContextFactory로 설정한다. 이 값은 기본적으로 엔진 컨테

이너가 기동될 때 설정되므로 별다르게 고려할 필요는 없다.

JEUS 엔진 컨테이너에서 동작하지 않는 애플릿, 애플리케이션 클라이언트

등이 사용한다.

Client-side JNSLocal

Client-side JNSLocal을 사용하려면 java.naming.factory.initial 프로퍼티값을

jeus.jndi.JNSContextFactory로 설정한다.

Client-side JNSLocal은 일정시간 동안 통신이 없을 때 커넥션을 끊고, 다시

필요할 때 커넥션을 생성하는 등, 리소스를 효율적으로 관리한다. 다만 클라

이언트 컨테이너에서 동작하는 애플리케이션은 클라이언트 컨테이너가 실

행될 때는 이 값을 시스템 프로퍼티로 설정하기 때문에 애플리케이션에서 별

도로 설정할 필요는 없다.

6.2.3. JNDI 클러스터링

JNDI 트리는 JNSServer와 JNSLocal 간의 연결로 구성되어 있다. 이 구조는 하나의 컴포넌트(JNSLocal)

에서 객체에 대한 정보의 변화가 있을 때 다른 컴포넌트(JNSLocal)로 전달될 수 있도록 하며, 또한 여러

개의 노드를 지원(클러스터링)할 수 있도록 한다.


즉, JNDI Naming 클러스터링은 각각의 독립적인 JNDI를 하나의 확장된 JNDI 트리로 구성하는 것이라 할

수 있으며, 이때도 마찬가지로 각 JNDI 트리에서 발생하는 객체에 대한 정보의 변화가 있을 때에는 나머

지 다른 JNDI로 그 내용이 전달된다. 따라서 JNDI Naming 클러스터링 환경에서는, 하나의 Naming Server

에서 바인딩한 객체를 다른 여러 Naming Server에서 이 객체를 lookup할 수 있게 된다.

예를 들어, 다음 그림처럼 4개의 노드 A, B, C, D가 클러스터링을 구성하고 있는 환경에서 Node A에 obj1

이라는 객체를 'objName1'이라는 이름으로 바인딩하면, 이는 나머지 3개의 노드 B, C, D에도 이 객체가

전달된다. 따라서 처음에 클라이언트가 직접 바인딩을 시도한 Node A가 아닌 다른 3개의 노드에서도

'objName1'으로 lookup하면 obj1이라는 객체를 얻어올 수 있게 된다.

[그림 6.2] 클러스터링 환경에서 JEUS JNDI 아키텍처

JNS Server JNSLocalJEUS Node

Node A

Node C

Node B

Node D

각 노드의 JEUS Manager는 각각의 JNSServer를 관리할 책임을 가지고 있다. 각 JNSServer는 JEUS 시

스템이 기동될 때 시작되어서 다른 노드의 JNSServer와 연결된다. 각 JEUS 엔진은 InitialContext를 가져

옴과 동시에 JNSLocal이 JNSServer로 연결된다. 클라이언트가 JNDI 트리의 객체를 lookup할 때,

JNSLocal로 요청하고, 이어서 해당 노드의 JNSServer로 요청이 가게 된다. 그리고 이에 대한 객체를 클

라이언트가 받게 된다.

클러스터링 환경에서 원격으로 lookup

별도의 설정을 하지 않은 경우 JNDI lookup은 자신이 포함된 JEUS/JNDI 클러스터링 영역에 대해서 수행

된다. 그러나 애플리케이션이 클러스터링에 있지 않은 다른 JEUS Manager의 JNDI 서버에 있는 내용을

lookup할 때에는 PROVIDER URL(“JEUS Reference Book”의 “1.5. JNDI 시스템 프로퍼티” 참고)을 지정

해서 Context를 생성하거나 lookup할 때 JEUS에서 생성한 jh(jeus host) 프로토콜을 사용한 이름으로

lookup해야 한다. 이에 대한 내용은 “6.5. JNDI 프로그래밍”을 참고한다.


JNSServer replication

JEUS의 각 JNSServer는 다른 서버와 연결되어서 상호 작용하기를 기다리고 있다. 기존의 클러스터로 새

로운 노드가 들어오면, 새로 들어온 노드의 JNSServer는 시작할 때 이미 존재하는 다른 JNSServer로 통

보를 보내게 된다. 이때 각 JNSServer는 자신의 데이터를 새로 들어온 JNSServer로 전송하게 되며, 이렇

게 해서 새로 들어온 JNSServer에서도 기존에 bind되어 있는 객체를 lookup할 수 있게 된다.

이런 확장성으로 인해 이상 작동하여 재기동된 JNSServer는 다른 JNSServer로부터 JNDI 트리 정보를 받

아 정상 상태로 동작할 수 있다.

6.3. JNDI Naming Server 설정JNDI Naming Server는 JNSServer와 JNSLocal로 구성되어 있다. 이 둘은 서로 다른 설정을 가진다.

JNSServer에서는 JNSLocal의 커넥션을 받아들이는 설정과 다른 JNSServer와 접속하기 위한 설정이 필

요하고, JNSLocal은 JNSServer와 접속하기 위한 것과 JNDI 트리의 반영을 위한 설정이 필요하다.

본 절에서는 JNSServer와 JNSLocal을 설정하는 것에 대해서 설명한다.

6.3.1. JNSServer 설정

JNSServer의 설정은 JEUSMain.xml에 한다. 왜냐하면 JEUS Manager에서 JNSServer가 실행되기 때문

이다. 설정은 WebAdmin을 사용하는 것과 직접 XML 파일을 수정하는 방법이 있다.

다음은 JNSServer 설정을 하기 위해 JEUSMain.xml 파일을 설정한 예로, <naming-server>의 <server> 태

그는 다음과 같아야 한다.

[예 6.1] Naming server 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<naming-server>

<server>

<use-nio>true</use-nio>

<export-cos-naming>true</export-cos-naming>

<backlog-size>100</backlog-size>

<pooling>

<min>1</min>

<max>10</max>


</pooling>

</server>

</naming-server>

</jeus-system>



설명태그

Naming server 사이의 통신에 non blocking I/O를 사용할지를 설정한다.<use-nio>

대량의 클라이언트를 위해서는 non blocking I/O가 필수적이다.

CORBA COS Naming Service를 사용할지 설정한다. COS Naming Server는

JEUS_BASEPORT+4 포트로 할당된다.

<export-cos-naming>

EJB RMI/IIOP를 사용하는 경우에 사용한다.(기본값: false)

다른 Naming Server의 접속을 받아들이는 한계인 back log의 크기를 정한다.<backlog-size>

들어오는 요청을 처리하기 위해서 대기 중인 Worker Thread를 정한다.(min,

max, period)

<pooling>

이 파일을 수정한 다음, JEUS를 재시작해야만 변경된 내용이 적용된다.

6.3.2. JNSLocal 설정

JNSLocal은 놓이는 위치에 따라서 설정하는 법이 다르다.

Server-side JNSLocal 설정Server-side JNSLocal은 JNSLocal이 JEUS Manager와 같이 실행되는 것을 의미한다.

JEUSMain.xml을 직접 수정할 때는 <naming-server>의 <local>태그를 사용해서 다음과 같이 한다. 설정

파일을 수정한 후에는 JEUS를 재시작해야 변경 내용이 적용된다.

[예 6.2] Server-side JNSLocal 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<naming-server>

. . .

<local>

<pooling>

<min>1</min>

<max>10</max>


</pooling>

</local>

</naming-server>

. . .

</jeus-system>


설명태그

들어오는 요청을 처리할 Worker Thread를 정한다.(min, max, period)<pooling>


Client-side JNSLocal 설정

Client-side JNSLocal은 JVM이 서로 다른 JNSServer를 액세스한다. 그래서 JNSServer와 연결되어서

JNDI 트리의 내용을 반영하는 스레드가 존재한다. JEUS JNDI는 Thread Pool로 스레드를 관리한다. 이

Thread Pool은 JEUS 프로퍼티를 사용해서 설정하며, 기본값을 사용해도 무방하다.

Client-side JNSLocal의 프로퍼티를 설정하려면 JVM의 시스템 프로퍼티를 사용하거나 InitialContext의

Hash Table을 사용해야 한다.

다음은 Client-side JNSLocal의 프로퍼티의 종류이다.

● JNSContext.RESOLUTION

● JNSContext.CONNECT_TIMEOUT

● JNSContext.CONNECTION_DURATION

참고

1. 만약 EJB와 서블릿/JSP 같은 서버 측 객체에서 JNDI를 사용한다면 JEUS Manager에 의해서

Server-side JNSLocal을 사용해서 bind나 lookup되기 때문에 이런 프로퍼티를 설정할 필요가 없다.

2. 프로퍼티에 대한 자세한 내용은 “JEUS Reference Book”의 “1.5. JNDI 시스템 프로퍼티”를 참조한

다.

6.4. 클러스터링 환경에서 JNDIJEUS 노드 클러스터링 환경이 구성되어 있다면 JNDI를 클러스터링하기 위해서 별도의 작업은 필요없다.

JEUS 노드를 클러스터링하는 것에 대해서는 “제4장 JEUS 클러스터링”을 참고한다.

만약 JEUS 노드가 클러스터링된다면, 각 JNSServer도 자동적으로 클러스터링 환경을 구성한다.

JEUSMain.xml에 다른 노드의 정보를 설정하면 JEUS Manager가 클러스터 내의 다른 JNSServer로 접속

한다. JNSLocal은 각각의 JNSServer로 접속하고, 마치 클러스터링 환경이 아닌 것처럼 작동한다. 그러나

JNSLocal이 Client-side일 경우에는 Context.PROVIDER_URL에 접속하려는 JNSServer를 설정해야 한

다. 기본적으로 JNSLocal은 로컬 JNSServer로 접속한다.

6.4.1. Binding 옵션 설정

클러스터에 있는 클라이언트는 JNDI 트리에 bind되어 있는 어떤 객체든 lookup할 수 있다. 만약 클라이언

트가 JNSLocal에 객체를 bind한다면 곧 JNSServer를 통해서 모든 노드에서 그것을 공유하게 된다. 또한

데이터 삭제나 변경이 발생하면 곧 각 노드의 JNSLocal에도 반영된다.

JEUS JNDI에서는 객체의 성격에 따라서 bind하는 3가지 옵션을 제공한다. 어떤 객체는 클러스터 전체에

공유되고, 또 어떤 객체는 자신의 노드에서만 존재한다거나, 또 어떤 것은 자신의 JVM 내에서만 보여야

할 경우가 있다.

● InitialContext의 Hash Table 사용

● JVM 옵션 ‘-D’ 사용


● Context 클래스의 addToEnvironment() 메소드 사용

기능을 사용하려면 다음의 3가지 프로퍼티를 설정해야 한다.

– REPLICATE_BINDINGS

– CACHE_BINDINGS

– LOCAL_BINDINGS

다음은 REPLICATE_BINDINGS와 CACHE_BINDINGS 옵션을 사용하고, LOCAL_BINDING을 사용하

지 않는 예제이다.

ctx.addToEnvironment(JNSContext.REPLICATE_BINDINGS, “true”);

ctx.addToEnvironment(JNSContext.CACHE_BINDINGS, “true”);

ctx.addToEnvironment(JNSContext.LOCAL_BINDINGS, “false”);

ctx.bind(“name”, object);

다음은 addToEnvironment() 메소드의 설정 프로퍼티에 대한 설명이다.

● REPLICATE_BINDINGS

– JNDI 트리 전체로 객체를 사용하려면 JNSLocal은 객체를 JNSServer로 전송해야 한다. 그러면

JNSServer는 연결되어 있는 모든 JNSServer로 그 객체를 넘기게 된다.

설명설정값

객체는 모든 JNSServer로 퍼진다.(기본값)true

로컬 노드의 JNSServer 내에서만 유지한다.false

– 다음은 객체가 복제되는 과정에 대한 설명이다.

[그림 6.3] Replicate Bind


● CACHE_BINDINGS

– 클라이언트가 객체를 lookup하면, JNSLocal은 항상 JNSServer로부터 객체를 lookup 해온다. 같은

객체를 여러 번 lookup하여 사용할 경우에는 객체를 캐싱하여 사용하면 매번 JNSServer에서 객체를

가져오는 오버헤드를 줄일 수 있다.

설명설정값

클라이언트에서 이 객체를 lookup했을 때 lookup을 한 후 바로 JNSLocal의 저장소에 캐

싱(Caching)한다. 이후부터는 JNSLocal은 JNSServer로부터 객체를 lookup하지 않고

Cache된 객체를 사용한다.(기본값)

true

클라이언트에서 이 객체를 lookup했을 때 lookup을 한 후 바로 JNSLocal의 저장소에 캐

싱(Caching)하지 않는다.

false

– 다음은 Cache된 객체를 전달하는 과정에 대한 설명이다.

[그림 6.4] Cache Bind

● LOCAL_BINDINGS

– 객체를 JNDI 트리의 모든 곳에서 보이길 원하지 않으면 LOCAL_BINDINGS를 사용한다.

설명설정값

JNSLocal에만 bind되고, 클라이언트의 요청은 JVM 내에서만 처리된다.true

JNSServer에 객체가 bind되어, 해당 매니저로 요청이 들어온 모든 경우에 사용할 수 있

다.(기본값)

false

– 다음은 객체가 JNSLocal에서만 bind되고 JNSServer없이 lookup되는 과정에 대한 설명이다.


[그림 6.5] Local Bind

6.5. JNDI 프로그래밍JEUS JNDI를 사용하는 프로그래밍 방법에 대해서 설명한다.

Java 클라이언트는 InitialContext를 사용해서 JNDI 트리를 접근한다. InitialContext에 사용되는 프로퍼티

는 JNDI 표준 프로퍼티와 JEUS용 프로퍼티가 있다.

먼저 JNDI 환경을 설정하고, 그 다음으로 InitialContext를 사용해서 객체를 lookup한 다음, 객체의 레퍼런

스를 가져온다. 마지막으로 InitialContext를 사용한 다음에는 반드시 close시켜준다.

다음의 과정으로 Java 클라이언트는 JEUS JNDI 서비스를 사용한다.

1. JEUS 환경설정

2. InitialContext를 위한 프로퍼티 설정

3. Context를 사용한 Named Object의 lookup

4. Named Object를 사용해서 객체의 레퍼런스 취득

5. Context 닫기

다음은 각 단계별 자세한 설명이다.

6.5.1. JEUS 환경설정

JNDI 서비스에서 필요한 클래스를 사용할 수 있도록 JEUS 클라이언트 모듈의 경로(JEUS_CLIENT)를 클

래스 패스에 설정한다.

-classpath %JEUS_CLIENT%;


6.5.2. InitialContext를 위한 프로퍼티 설정

Java 클라이언트가 JEUS JNDI 서비스를 사용하기 전에 우선 InitialContext의 환경 프로퍼티를 설정한다.

설정하는 방법은 다음의 2가지가 있다.

● JVM의 ‘-D’ 옵션을 사용한다.

● Hash Table을 생성하여 InitialContext의 생성자에게 넘긴다.

위의 2가지 방법 중, Hash Table을 생성하여 InitialContext의 생성자에게 넘기는 방법보다 JVM의 '-D' 옵

션을 사용하는 방법이 우선한다.

JEUS JNDI의 InitialContext를 생성하기 위해서 설정해야 하는 프로퍼티는 다음과 같다.

● Context.INITIAL_CONTEXT_FACTORY (required)

● Context.URL_PKG_PREFIXES

● Context.PROVIDER_URL

● Context.SECURITY_PRINCIPAL

● Context.SECURITY_CREDENTIALS

참고

프로퍼티에 대한 자세한 사항은 “JEUS Reference Book”의 “1.5. JNDI 시스템 프로퍼티”를 참조한다.

이 프로퍼티들을 Hash Table에 넣어서 InitialContext를 생성할 때 사용한다. 만약 서버 측 객체 내(EJB나

서블릿/JSP)에서만 InitialContext를 사용한다면 별도의 설정 없이 기본으로 설정된 InitialContext를 사용

한다.

클라이언트 프로그램에서는 다음과 같이 설정한다.

Context ctx = null;

Hashtable ht = new Hashtable();

ht.put(Context.INITIAL_CONTEXT_FACTORY, "jeus.jndi.JNSContextFactory”);

ht.put(Context.URL_PKG_PREFIXES, “jeus.jndi.jns.url”);

ht.put(Context.PROVIDER_URL, “<hostname>”);

ht.put(Context.SECURITY_PRINCIPAL, “<username>”);

ht.put(Context.SECURITY_CREDENTIALS, “<password>”);

try {

ctx = new InitialContext(ht);

// use the context

} catch (NamingException ne) {

// fail to get an InitialContext

} finally {

try{

ctx.close();


catch (Exception e) {

// an error occurred

}

}

클러스터링 환경에서 JNDI를 사용할 때는, JNDI 트리를 구성하고 JNSLocal의 내부적인 작동을 효과적으

로 관리하기 위해서 jeus.jndi.JNSContext의 추가적인 환경 프로퍼티를 사용할 수 있다.

● Hash Table을 사용해서 Context 생성하기

InitialContext의 환경 프로퍼티를 설정할 때 Hash Table(java.util.Hashtable)의 키로 프로퍼티 이름을 넣

고, 값으로 프로퍼티의 데이터를 넣은 후에 InitialContext 생성자의 파라미터로 넣어준다.

● Security Context 생성하기

JEUS Security 도메인의 사용자를 실행 스레드에 적용시키기 위해서 몇 가지 보안 관련 환경 프로퍼티

를 사용할 수 있다. InitialContext가 생성될 때 Security Context는 다음의 프로퍼티로 구성한다.

– 사용자명 프로퍼티 : java.naming.security.principal

– 패스워드 프로퍼티 : java.naming.security.credentials

인증이 성공하면 인증된 사용자의 정보가 실행 스레드에 설정되며, JEUS Security Manager가 관리하는

리소스를 액세스할 수 있다. 만약 인증에 실패하면 스레드는 guest 사용자로 인식된다.

만약 Security Context가 설정되어 있다고 하더라도 InitialContext가 생성되기 전에 JEUS Security API를

사용해서 로그인한 경우 Security Context는 무시된다. 즉, 이미 로그인된 subject를 사용해서 JNDI 통신

을 수행한다.

참고

1. 사용자 정보 세팅에 관한 더 자세한 내용과 JEUS Security Service에 대한 내용은 "JEUS Security

안내서"를 참조한다.

2. 환경 프로퍼티에 대한 자세한 것은 “JEUS Reference Book”의 “1.5. JNDI 시스템 프로퍼티”를 참

조한다.

6.5.3. Context를 사용한 Named Object의 lookup

JNDI 트리에 bind된 객체는 JNDI Context의 lookup() 메소드를 사용해서 찾는다. 다음은 lookup하려는 객

체의 이름이 ejbAppHome1인 경우의 예제이다.

try {

Context ctx = new InitialContext();

AppHome appHome1 = (AppHome)ctx.lookup(“ejbAppHome1”);

// successfully got the object

} catch (NameNotFoundException ex) {

// no such binding exists

} catch (NamingException e) {



}

6.5.4. Named Object를 사용

lookup한 객체를 사용한다.

다음은 EJB 클라이언트에서는 lookup한 EJB 홈 객체의 create() 메소드를 사용해서 EJB 리모트 객체의

레퍼런스를 가져오는 예제이다. 예와 같이 메소드를 실행해서 사용하려는 객체의 레퍼런스를 가져오고,

그 객체 레퍼런스의 메소드를 실행한다.

AppBean bean = appHome1.create();

bean.service();

6.5.5. Context 닫기

다음과 같이 Context를 사용한 다음에는 close()메소드를 실행해서 Context를 닫아준다.

try {

cx.close();

} catch(Exception e) {


}

6.5.6. Context 생성

JEUS 클러스터링 환경에서 사용할 수 있는 Context를 생성하기 위해서는 다음과 같이 Con

text.PROVIDER_URL에 여러 개의 호스트를 설정한다.

Hashtable ht = new Hashtable();

ht.put(Context.PROVIDER_URL, "host1:9736,host2:9736");

6.5.7. 원격으로 lookup 실행

애플리케이션이 클러스터링에 있지 않은 다른 JEUS Manager의 JNDI 서버에 있는 내용을 lookup할 때에

는 PROVIDER URL을 지정해서 Context를 생성하거나 lookup할 때 JEUS에서 생성한 jh(jeus host) protocol

을 사용한 이름으로 lookup해야 한다.

다음은 JEUS의 클러스터링 환경에서 원격으로 lookup을 실행할 수 있도록 하는 특별한 lookup 구문이다.

이 구문은 자신이 속한 JEUS/JNDI 클러스터링의 영역을 벗어나 원격지의 JEUS/JNDI 클러스터링에 있는

객체를 lookup할 때 사용한다.


jh:<remote JEUS host name>:<remote JEUS base port>/<export name>

("jh" = JEUS host)

다음은 lookup 구분의 사용법으로 JNDI Context 문자열 내에 다음과 같은 구문을 입력한다.

try {


AppHome appHome1 = (AppHome)ctx.lookup("jh:dev:9736/ejbAppHome1");

// successfully got the object

} catch (NameNotFoundException ex) {

// no such binding exists

} catch (NamingException e) {


}


제7장 External Resource

본 장에서는 JEUS와 연동하여 하나의 시스템을 구축할 수 있는 다양한 외부 리소스에 대한 소개와 설정

방법에 대해 설명한다. 한가지 주의할 점은, 외부 리소스에 대한 설정은 각 제품의 특성에 좌우될 수 밖에

없으므로 속성이나 사용법에 관한 내용들은 각 외부 리소스의 매뉴얼을 참고해야 한다.

7.1. 리소스 종류외부 리소스는 애플리케이션이 JEUS를 통해서 접근할 수 있는 JEUS 외부에 존재하는 리소스를 말한다.

데이터베이스가 대표적인 예이다. 이러한 리소스들은 JEUS에 관련 설정을 추가함으로써 연결이 가능하

다.

참고

만약 외부 리소스에서 JCA 표준 호환의 리소스 어댑터를 제공하는 경우에는 리소스 어댑터를 Deploy

해서 사용하길 권장한다.

다음은 JEUS에 설정할 수 있는 리소스이다.

● 데이터 소스

데이터 소스는 JDBC 호환 데이터베이스를 의미한다.

데이터 소스는 클라이언트에서 직접적으로 접근 할 수 있는데 이런 경우에는 특별히 JEUS에 설정을 하

지 않아도 된다. 그러나 데이터 소스를 설정하면 JNDI를 이용해서 JDBC Connection Pool을 사용할 수

있으므로 애플리케이션이 더욱 편리하게 데이터베이스에 접근할 수 있다. 데이터 소스의 설정은 “제8

장 DB Connection Pool과 JDBC”를 참고한다.

● 메일 소스

메일 소스는 SMTP와 같은 메일 프로토콜을 이용하여 클라이언트 애플리케이션으로부터 e-mail을 전

송할 때 사용한다. JEUS에서는 JNDI Export name에 e-mail 호스트의 정보를 Bind하고, 클라이언트에

서 간접적으로 접근하여 호스트를 사용하도록 한다. JNDI를 lookup하면 javax.mail.Session 타입의 메

일 소스를 가져온다.

● URL 소스

URL 소스는 애플리케이션에서 외부 URL 객체를 JNDI를 통해 접근할 수 있도록 한다. URL이 변경되는

경우 해당 URL 설정을 수정함으로써 애플리케이션의 소스 수정 없이 그대로 사용할 수 있도록 한다.

JNDI를 lookup하면 java.net.URL 타입의 URL 객체를 가져온다.

제7장 External Resource 77

● 외부 소스 - IBM MQ, Sonic MQ 등

JEUS와 연결 할 수 있는 비정규화된 소스들을 말한다. 일반적으로 JEUS에 설정할 수 있는 것으로는

IBM MQ, Sonic MQ 등의 JMS(Java Message Service) 제품들과 Tmax TP Monitor 등이 있다.

이 리소스들은 JEUS에 설정하지 않아도 Java API를 통해서 직접적으로 액세스 할 수도 있다. 그러나

트랜잭션 매니저에서 이 소스들을 관리하려면 설정을 해야 한다(“제9장 트랜잭션 매니저” 참조).

● JAXR 소스

JAXR 소스는 JavaEE JAXR 클라이언트가 JNDI로부터 JAXR 커넥션을 얻어 올 수 있는 환경을 제공하

기 위하여 사용한다. JEUS에서는 JNDI를 사용하여 JAXR ConnectionFactory를 lookup할 수 있다.

7.2. 리소스 설정본 절에서는 각각의 외부 리소스들을 JEUSMain.xml에 설정하는 방법을 설명한다.

하나의 <resource> 태그 안에 각각 사용할 리소스에 대한 설정이 들어가는데, 이는 JEUSMain.xml 파일

의 최상위 element인 <jeus-system> 하위에 존재한다.

[예 7.1] 리소스 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

<data-source>

. . .

</data-source>

<mail-source>

. . .

</mail-source>

<url-source>

. . .

</url-source>

<external-source>

. . .

</external-source>

<jaxr-source>

. . .

</jaxr-source>

</resource>

</jeus-system>

다음은 리소스 종류에 따른 설정법에 대해 설명한다.


7.2.1. 데이터 소스의 설정

데이터 소스는 데이터베이스 관련 설정을 다루게 된다. 이 내용은 “제8장 DB Connection Pool과 JDBC”에

기술되어 있으므로 해당 절을 참고한다.

7.2.2. 메일 소스의 설정

메일 소스는 <mail-source>에 설정한다. 각각의 SMTP 서버마다 <mail-source>의 <mail-entry>에 각각의

e-mail 호스트에 대한 정보가 들어가게 된다. 이 정보는 JavaMail 스펙을 참고한다.

<mail-entry> 태그의 설정은 다음과 같다.

설명태그

JNDI에 Binding될 이름을 지정한다. 설정된 이름으로 java.mail.Session 객체가

Bind된다.

<export-name>

메일 호스트에 대한 속성들을 결정한다. <name>과 <value> 태그의 짝으로 구성

된다. 이 중 속성의 이름(<name> 태그에 쓰임)은 JavaMail 스펙을 따르므로, 스펙

을 참고하여 지정하도록 한다.

<mail-property>

7.2.3. URL 소스의 설정

URL 소스는 <url-source>에 설정한다. 각각의 URL 별로 하위 태그인 <url-entry> 태그를 추가한다.

다음은 JNDI 이름은 PRIMARY_URL과 SECONDARY_URL이고 각각에 바인드되는 URL은

http://www.foo.com과 http://www.bar.com로 설정한 예이다.

[예 7.2] URL 소스의 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

. . .

<url-source>

<url-entry>

<export-name>

PRIMARY_URL

</export-name>

<url>

http://www.foo.com

</url>

</url-entry>

<url-entry>

<export-name>

SECONDARY_URL

</export-name>


<url>

http://www.bar.com

</url>

</url-entry>

</url-source>

. . .

</resource>

</jeus-system>

다음은 <url-entry> 하위 태그에 대한 설명이다.

설명태그

JNDI에 Binding될 이름을 지정한다. 이 이름으로 java.net.URL 객체가 Bind된다.<export-name>

실제 URL 주소를 설정한다.<url>

7.2.4. 외부 소스의 설정

외부 소스는 크게 Tmax TP Monitor와 JMS(Java Message Service) 소스로 나뉜다. <external-resource>

태그 하위에는 <jms-source>, <tmax-source>의 2가지 태그가 등장하여 각각에 대한 설정을 담당한다.

JMS 소스(JMS Source)다음은 외부 JMS소스 설정한 예제이다.

[예 7.3] JMS 소스 설정 : <<JEUSMain.xml>

<jeus-system>

. . .

<resource>

. . .

<external-source>

<jms-source>

<vendor>ibmmq</vendor>

<factory-class-name> ... </factory-class-name>

....

<property>

<name>blah</name>

<type>java.lang.String</type>

<value>abcd-efg</value>

</property>

</jms-source>

</external-source>

. . .

</resource>

</jeus-system>


다음은 <jms-source>의 하위 태그에 대한 설명이다.

설명태그

JMS 벤더를 명시한다.<vendor>

다음의 값 중 하나를 설정한다.

- ibmmq : IBM사의 제품을 지칭한다.

- sonicmq : Sonic MQ를 지한다.

- others : 그 외의 제품들을 지칭한다.

해당 JMS 리소스의 Factory Class의 이름을 지정한다.<factory-class-name>

해당하는 JMS의 타입을 결정한다.<resource-type>

값으로는 QCF, TCF, Q, T, XAQCF, XATCF, LOCALXAQCF, LOCALXATCF

의 8가지의 타입이 있다.

JNDI에 Binding될 이름을 지정한다. 사용자는 이 이름을 이용하여 JMS의

ConnectionFactory, Destination 등을 이용할 수 있다.

<export-name>

<resource-type>이 Q일 때만 사용한다.<queue>

<resource-type>이 Q일 때만 사용한다.<queueManager>

<resource-type>이 T일 때만 사용한다.<topic>

JMS 리소스에 필요한 속성들을 기록한다. 이 태그는 <name>, <type>, <value>

로 구성된다.

<property>

참고

각 태그에 대한 자세한 내용은 자세한 것은 IBM MQ나 Sonic MQ의 매뉴얼을 참조한다.

7.2.5. JAXR 소스의 설정

JEUS에서 JNDI를 사용하여 JAXR ConnectionFactory를 lookup하기 위해서는 <jaxr-source>, <jaxr-entry>

하위에 다음과 같이 등록한다.

[예 7.4] JAXR 소스의 설정 : <<JEUSMain.xml>

<jeus-system>

. . .

<resource>

. . .

<jaxr-source>

<jaxr-entry>

<export-name>REGISTRY_NAME</export-name>

<query-manager-URL>

http://localhost:8088/uddi/inquiry


</query-manager-URL>

<lifeCycle-manager-URL>

http://localhost:8088/uddi/publish

</lifeCycle-manager-URL>

</jaxr-entry>

</jaxr-source>

</resource>

. . .

</jeus-system>


설명항목

Target registry provider의 query manager 서비스를 위한 URL이다.<query-manager-URL>

Target registry provider의 life cycle manager 서비스를 위한 URL이다.<lifeCycle-manager-URL>

참고

보다 자세한 사항은 “JEUS Web Service 안내서”의 “제18장 JavaEE 환경에서 JAXR Connection을

얻는 방법”을 참고한다.


제8장 DB Connection Pool과 JDBC

본 장에서는 JEUS에서 제공하는 Connection Pool 및 부가 기능들에 대해 설명하고 그 사용법에 대해 설

명한다.

8.1. 개요웹 애플리케이션은 정보 저장이 필요할 때 주로 데이터베이스(Database, 이하 DB)를 이용한다. 이를 위해

JEUS와 같은 WAS(Web Application Server)는 애플리케이션이 DB로 접근할 수 있는 통일된 방법을 제공

해야 한다. 이러한 통일된 DB 접근을 위해 만든 표준이 바로 JDBC(Java Database Connectivity) 표준이

다. JDBC 표준은 애플리케이션이 DB 커넥션을 사용하는 방법에 대해 기술하고 SQL 작업을 하기 위한

API를 제공하고 있다. 표준에 관한 자세한 내용은 Sun JDBC 페이지(http://www.oracle.com/technetwork/ja

va/javase/tech/index-jsp-136101.html)를 참고한다.

JEUS에서는 애플리케이션의 원활한 DB 사용을 위해 Connection Pool과 여러 부가 기능들을 제공한다.

8.2. JDBC Connection PoolJDBC는 Java 애플리케이션이 DB에 접속하기 위한 Java 표준 API이다. 현재 JEUS는 JDBC 3.0을 지원

하고 있다. JDBC 표준에 관한 좀 더 자세한 사항은 관련 웹 페이지 또는 서적을 참고한다.

JEUS에서는 응용 프로그램의 효율적인 DB 사용을 위한 Connection Pool을 제공한다. 사용자는 그러한

기능들을 사용하기 위하여 이하 소개되는 내용들을 숙지하고 알맞은 설정을 해야 한다.

Connection Pool 사용의 이점들은 다음의 2가지로 요약할 수 있다.

● 보다 높은 성능

DB 커넥션 생성은 처리 과정이 느리다. Connection Pool 안에서의 모든 실제 커넥션들은 미리 만들어

져 애플리케이션의 요청 처리를 위한 준비가 되어 있다. 커넥션을 더 이상 사용하지 않을 때에는 그것을

Pool에 반환시켜서 커넥션 중단의 오버헤드를 감소시킬 수 있다.

● 연결 관리

동시 커넥션들의 수를 제어할 수 있다. 동시 커넥션들의 최대 수를 구성함으로써 DB의 동시 커넥션을

제한하는 작업을 효율적으로 할 수 있다.

JEUS의 Connection Pool은 서버 기동 시점에 생성되지 않고 실제 서비스를 호출할 때 생성된다. 만약

Connection Pool을 생성하고 싶다면 jeusadmin 또는 WebAdmin을 통해서 생성할 수 있다. Connection

Pool 생성 방법에 관한 좀 더 자세한 사항은 “JEUS Reference Book”의 “4.2.7. DB Connection Pool 관련

명령어”을 참고한다.

제8장 DB Connection Pool과 JDBC 83

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136101.html

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136101.html

JDBC 드라이버JEUS는 JDBC 인증을 받은 드라이버들을 지원한다. 인증된 드라이버의 타입이나 그 종류는 Sun의 'Types

of JDBC technology drivers' (http://www.oracle.com/technetwork/java/javase/jdbc/index.html) 문서에서

찾을 수 있다. JEUS의 JDBC 환경 구성은 어떤 벤더의 DB를 사용하느냐에 따라 환경 구성이 서로 다를

수 있다. 이는 각 드라이버마다 각자 요구하는 속성이 다르기 때문이므로 각 벤더의 JDBC 드라이버 매뉴

얼을 참고해야 한다.

8.2.1. Connection Pooling

Connection Pooling은 DB 커넥션을 위한 하나의 프레임워크(Framework)이다. Connection Pool이 시작

될 때 특정한 수의 물리적 커넥션을 만들며 이는 애플리케이션 실행 중에 커넥션 생성을 위한 오버헤드

(Overhead)를 줄여준다.

다음 그림은 JEUS JDBC Connection Pooling의 전체적인 구조를 보여준다.

[그림 8.1] JEUS의 Connection Pooling

Client

Application

JEUS

Data Source

Connection PoolServer

Application

(e.g. EJB,

Servlet

Connection

Connection

Connection

Connection

JNDI Look up

JDBC

Driver Database

8.2.2. 데이터 소스

데이터 소스는 애플리케이션과 Connection Pool 사이의 인터페이스이다. 애플리케이션이 사용하는 데이

터 소스 객체는 DB 커넥션들의 Factory로 볼 수 있으며 java.sql.DriverManager 보다 많은 이점을 제공한

다. 데이터 소스들은 4가지의 타입을 갖는다.

기본 데이터 소스

javax.sql.DataSource 타입을 의미한다. JEUS는 이 타입에 대해 Connection Pool을 제공하지 않으므로

Connection Pool 데이터 소스를 사용하기 바란다.


http://www.oracle.com/technetwork/java/javase/jdbc/index.html

Connection Pool 데이터 소스javax.sql.ConnectionPoolDataSource 타입을 의미한다. JEUS는 이 타입에 대해 Connection Pool을 제공

한다.

주로 다음과 같은 상황에서 사용할 수 있다.

● XA를 사용할 필요없이 간단하게 DB에 접근하기 위한 애플리케이션을 작성하는 경우

● auto-commit을 false로 설정하고 직접 로컬 트랜잭션을 컨트롤하는 경우

import java.sql.Connection;

Connection conn = datasource.getConnection();

conn.setAutoCommit(false);

.... DB 접근 코드 ... // JDBC 드라이버 내부적으로 로컬 트랜잭션 진행

conn.commit();

XA 데이터 소스javax.sql.XADataSource 타입을 의미한다. JEUS는 이 타입에 대해 Connection Pool을 제공한다.

글로벌 트랜잭션(XA)에 이용되는 커넥션을 관리하며, 주로 다음과 같은 상황에서 사용할 수 있다.

● 서블릿/EJB와 같은 Java EE 컴포넌트 로직이 2개 이상의 DB로 접근해야 하는 경우

● Java EE 컴포넌트에서 하나의 DB로 접근하더라도 관련 로직들이 일련의 동작으로 묶여야 하는 경우

이때 XA 처리 성능을 높이기 위해서 로컬 트랜잭션 최적화를 선택할 수 있다. 이에 관한 자세한 사항은 로

컬 XA 데이터 소스를 참고한다.

로컬 XA 데이터 소스Connection Pool 데이터 소스를 통해서 얻은 커넥션을 XA에 참여하도록 에뮬레이션 해주는 데이터 소스

이다. JEUS는 이 타입에 대해 Connection Pool을 제공한다. 이 타입은 주로 다음과 같은 상황에서 사용할

수 있다.

● DB가 XA를 지원하지 않거나 JDBC 드라이버가 javax.sql.XADataSource 구현체를 지원하지 않는 경우

● 애플리케이션에서 XA(글로벌 트랜잭션)가 필요하지만 성능 문제로 XA 데이터 소스를 사용하고 싶지

않은 경우. 즉, 로컬 트랜잭션 최적화가 필요한 경우

최근에는 XA를 지원하지 않는 DB 또는 JDBC 드라이버는 거의 없다고 볼 수 있기 때문에 주로 로컬 트랜

잭션 최적화를 위해서 이 데이터 소스를 사용하게 될 것이다. 그러나 반드시 고려해야 할 제약 사항이 있

다. 바로 하나의 XA에는 최대 하나의 로컬 XA 데이터 소스만 참여할 수 있다는 것이다.

따라서 로컬 XA 데이터 소스는 되도록 다음과 같은 상황에서 사용하기 바란다.


● 서블릿/EJB와 같은 Java EE 컴포넌트 로직이 하나의 DB만 사용하기 때문에 굳이 XA 데이터 소스를 사

용할 필요가 없을 때

● Java EE 컴포넌트에서 여러 개의 DB를 사용하더라도 그 중 하나를 로컬 트랜잭션으로 처리해서 XA 성

능을 높이고 싶을 때

여러 개의 DB를 사용하는 상황에서 주의할 점은, 로컬 XA 데이터 소스는 실제로 2PC(2 Phase Commit)

를 지원하는 것이 아니므로 트랜잭션 Recovery가 제대로 되지 않을 수 있다.

타 WAS 벤더(주로 WebLogic)와는 달리, 다음과 같이 Connection Pool 데이터 소스에 LocalXADataSource

타입을 지정하는 방식이다. 차기 버전에서는 사용자의 혼란을 줄이기 위해서 타 WAS벤더의 설정과 유사

하게 변경될 예정이다.

<data-source>

<database>

<vendor>tibero</vendor>


<data-source-class-name>

com.tmax.tibero.jdbc.ext.TbConnectionPoolDataSource

</data-source-class-name>

<data-source-type>LocalXADataSource</data-source-type>

.....

</database>

....

</data-source>

참고

로컬 XA 데이터 소스에서 얻은 커넥션이 XA에 참여할 때는 auto-commit을 끄고 사용하는 로컬 트랜

잭션이 되기 때문에 DB 입장에서는 JEUS 트랜잭션 매니저가 관리하는 XA 트랜잭션과는 서로 다른

트랜잭션이다. 대신 JEUS에서는 로컬 트랜잭션이 그 XA 트랜잭션에 참여할 수 있도록 에뮬레이션

해서 애플리케이션 입장에서는 같은 트랜잭션으로 처리해주는 것이다.

지금까지 JEUS 설정에서 제공하는 다양한 데이터 소스 형식을 살펴보았다. 데이터 소스에는 다양한 종류

가 있고 각각 필요한 상황이 있으므로, 애플리케이션에서 성능과 비즈니스 로직을 고려해서 그에 맞는 타

입을 사용해야 한다.

8.2.3. 클러스터 데이터 소스 및 장애복구 기능

JEUS 레벨에서 RAC 인스턴스 간의 Failover & Failback을 제공하기 위해서 클러스터 데이터 소스(Cluster

Data Source)를 제공한다. RAC는 Real Application Cluster의 약자로 Oracle에서 제공하는 DB 클러스터

링 기능이다. RAC에 관한 자세한 내용은 Oracle의 문서를 참고한다.

클러스터 데이터 소스는 근본적으로는 하나의 JNDI 이름을 가진 데이터 소스 인스턴스이다. 이 인스턴스

는 애플리케이션의 요청을 우선 주 RAC 인스턴스로 전달시켜주는 역할을 한다. 만약 주 인스턴스가 종료

(Down)되었을 경우, 백업 RAC 인스턴스가 선택되어서 요청 사항을 처리하게 된다. 애플리케이션에서는

단지 하나의 데이터 소스만 보게 되므로 장애복구가 투명하게 처리된다.


[그림 8.2] RAC에서 클러스터 데이터 소스 Failover 기능

Application

AP

RAC

Instance 2

with “RAC2”

Cluster Data

Source with

export name

"RAC"

RAC

Instance 1

with “RAC1”

Lookup Data

Source “RAC”

Request to the

primary instance

“RAC1”

“RAC2” will be

used when

“RAC1” is down

그리고 Oracle JDBC 드라이버 레벨에서 제공하는 CTF(Connect Time Failover)보다는 JEUS의 클러스터

데이터 소스를 사용하길 권장한다. Oracle CTF의 경우에는 커넥션 별로 Failover를 하기 때문에 데이터

소스 전체가 문제가 생겼을 경우 Pool에 있는 모든 커넥션마다 Failover를 해야 하기 때문에 성능이 떨어

진다. 그러나 JEUS 클러스터 데이터 소스에서는 데이터 소스에 문제가 생긴 것을 감지하면 데이터 소스

단위로 Failover를 하므로 더 효율적이며, 자동으로 Failback을 하는 기능도 제공한다.

참고

JEUS의 클러스터 데이터 소스를 사용하는 방식과 Oracle JDBC 드라이버에 RAC 속성을 설정하는

방식은 서로 동작이 다르다는 점에 주의해야 한다. 전자는 Failover를 JEUS가 처리하는 것이기 때문

에 각 RAC 인스턴스의 FAIL 여부를 감지하기 위해서 check-query와 check-query-period를 설정해

야 한다. 그러나 후자는 드라이버가 Failover를 담당하게 되므로 check-query가 필수적인 것은 아니

다.

주의

JEUS 6 fix#3부터는 기본적으로 Failback을 지원하므로 이를 위한 설정이 반드시 필요하다. 클러스

터 데이터 소스 설정에 관한 내용은 “8.3.5. 클러스터 데이터 소스 설정”을 참고한다.

8.3. JDBC 데이터 소스 설정JEUS에서 JDBC 드라이버 구성을 시도할 때 JEUS_HOME\lib\datasource\ 디렉터리 내에 JDBC 드라이

버 클래스 라이브러리가 존재하는지 먼저 확인한 후 다음 절과 같이 JEUSMain.xml을 구성하거나, WebAd

min을 통해 설정을 해야 한다. 대부분의 경우 WebAdmin을 통해 이를 설정할 것을 권장한다.

8.3.1. 데이터 소스 관리

JEUS 6 Fix#7에서 데이터 소스를 노드 내의 특정 엔진 컨테이너에서만 사용할 수 있는 기능이 추가되었

다. 이에 따라 데이터 소스를 관리하는 방식이 변경되었다.


JEUS 6 Fix#6까지는 데이터 소스를 설정하면 모든 엔진 컨테이너에서 사용할 수 있다. 하지만 같은 컨테

이너 별로 Connection Pool 설정을 서로 다르게 설정하고 싶은 요구사항이 자주 발생하였는데, 기존의 구

조에서는 지원할 수가 없었고, 이는 타 벤더와 비교해 약점으로 지적되었다. 엔진 컨테이너마다 서로 다른

데이터 소스를 사용하게 하는 게 한 가지 방법이지만 export-name이 서버에서 관리하는 키로 사용되어 다

른 데이터 소스는 다른 export-name을 정의해야 하고, 이는 lookup하는 이름이 달라지므로, 어떤 컨테이

너에 Deploy하느냐에 따라 애플리케이션을 바꿔야 하는데 이는 좋지 않은 방법이다.

이에 대한 해결 방법으로 JEUS 6 Fix#7에서는 data-source-target을 추가하고, 그동안 암시적으로 export-

name을 데이터소스 관리 키로 사용하던 방식에서 데이터 소스 ID를 명시적으로 입력하는 방식으로 바뀌

었다. 바꿔 말하면 이제 더 이상 export-name을 데이터 소스를 구별하는 이름으로 사용하지 않기 때문에

서로 다른 데이터 소스가 같은 export-name을 설정할 수 있다. 물론 같은 export-name을 사용하는 서로

다른 데이터 소스들이 같은 엔진 컨테이너를 Target으로 지정한다면 해당 컨테이너에서 제대로 동작하지

않지만, 이런 충돌만 조심하면 문제 없이 동작한다.

그러면 위에서 문제라고 설명한 부분은 다음의 방법으로 해결할 수 있다.

예를 들어 애플리케이션에서 DS1이라는 이름으로 데이터 소스를 lookup하는 로직을 짜고, 컨테이너

container1, container2에 각각 Deploy하는 경우를 생각해 보자.

이 경우에 container1에 알맞는 Connection Pool 설정값들로 만든 데이터 소스를 datasource1이라는 ID

로 만들고, container2에 알맞는 Connection Pool 설정값들로 만든 데이터 소스를 datasource2라는 ID로

만들면 같은 export-name이지만 컨테이너별로 Connection Pool 구성을 다르게 해서 사용할 수가 있다.

물론 target과 export-name은 상황에 맞게 잘 설정해야 한다.

8.3.2. 기본 설정

JEUSMain.xml에 데이터 소스를 설정할 수 있다. javax.sql.DataSource의 속성들은 각 드라이버별로 다르

기 때문에 사용하기 원하는 드라이버의 특성을 파악하고 그 특성에 맞게 설정을 해야 한다.

참고

각 태그들의 전체 리스트는 "JEUS_HOME\docs\reference\schema\index.htm"에 있는 XML Reference

에서 찾을 수 있다. 또한 JDBC 구성 예제들은 “Appendix B. JDBC Data Source 구성 예제”를 참고한

다.

다음은 Oracel 데이터 소스로 설정한 예제로 <resource><data-source>...<database> XML 태그에 설정

한다.

[예 8.1] JDBC 데이터 소스 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

<data-source>

<database>

<vendor>oracle</vendor>

<data-sourcce-id>datasource1</data-source-id> 

<export-name>jdbc/ds1</export-name>



<data-source-target>johan_container1</data-source-target>


oracle.jdbc.pool.OracleConnectionPoolDataSource


<data-source-type>ConnectionPoolDataSource</data-source-type>

<database-name>ora9i</database-name>

<description>

This is a sample for database setting.

</description>

<user>scott</user>

<password>tiger</password>

<port-number>1521</port-number>

<server-name>192.168.1.2</server-name>

<property>

<name>driverType</name>


<value>thin</value>

</property>

<auto-commit>true</auto-commit>

<action-on-connection-leak>Warning</<action-on-connection-leak>

. . . 

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


설명태그

DB 벤더의 이름을 설정한다. 현재 사용하고 있는 DB의 벤더 이름을 사

용하고, 나열되지 않은 DBMS는 others로 설정하도록 한다.

<vendor>

"oracle”, “mssql”, “db2”, “sybase”, “tibero”, “others”

노드에서 관리하는 데이터 소스 ID를 설정한다.<data-source-id>

JEUS 6 Fix#7에 추가되었고, JEUS 6 Fix#0 ~ Fix#6 버전에서는 export-

name이 데이터 소스 ID 역할을 한다.

JNDI에 바인딩될 이름을 설정한다.<export-name>

이름으로 데이터 소스 객체가 Bind된다. 데이터 소스 ID가 설정되지 않

은 경우 여기에 설정된 값을 내부적으로 ID로 사용한다.


설명태그

데이터 소스를 사용할 엔진 컨테이너 이름을 설정한다.<data-source-target>

JEUS 6 Fix#7에서 추가되었다. 설정하지 않으면 노드에 속한 모든 엔진

컨테이너에서 사용할 수 있다.

JDBC 드라이버별 데이터 소스 클래스 이름을 설정한다.<data-source-class-name>

사용하려는 데이터 소스 타입에 맞게 선택한다.<data-source-type>

“DataSource”, “ConnectionPoolDataSource”, “XADataSource”, “LocalX

ADataSource”

데이터 소스의 이름이다. 드라이버 벤더에 의존적이며 일반적으로

DataSourceClassName 값과 동일하다(Deprecated).

<data-source-name>

DB의 이름을 설정한다. Oracle의 경우 SID로 설정한다.<database-name>

Oracle inet 드라이버 사용하는 경우만 사용하며 Oracle의 SID 값을 설

정한다(Deprecated).

<service-name>

데이터 소스를 설명하는 내용의 텍스트를 설정한다.<description>

DB에 연결할 때 사용되는 프로토콜을 설정한다.<network-protocol>

예) Sybase의 "Tds" (Deprecated)

사용자의 패스워드를 설정한다. 패스워드를 암호화해서 사용할 경우

{algorithm}ciphertext 형식으로 입력한다.

<password>

(예 : {DES}FQrLbQ/D801DL28rw==)

허용되는 알고리즘 정보는 “JEUS Security 안내서”의 “제2장 보안 시스

템의 설정”에 설명되어 있다.

사용자의 이름을 설정한다.<user>

DB Listener의 포트 번호를 설정한다.<port-number>

DB가 운용 중인 서버의 DNS 이름이나 IP주소를 설정한다.<server-name>

Oracle의 경우 드라이버의 타입을 설정한다(예 : thin, oci) (Deprecated).<driver-type>

JDBC 커스텀 프로퍼티를 지정한다. 자세한 내용은 다음에 나오는 “8.3.3.

Custom DB 속성 추가”를 참고한다.

<property>

Connection Pooling에 특화된 내용을 설정해준다. 자세한 내용은 “8.3.4.

Connection Pool 설정”를 참고한다.

<connection-pool>

커넥션에 지정될 auto commit 값을 지정한다. true, false로 지정한다.<auto-commit>

로컬 XA 데이터 소스나 XA 데이터 소스의 경우에는 커넥션이 트랜잭션

에 연동되어 있지 않을 경우에만 적용한다.

JDBC 커넥션에서 java.sql.Statement 객체를 생성할 때 일괄적으로 타

임아웃을 적용한다.

<stmt-query-timeout>


설명태그

이 옵션은 JDK 1.4 이상에서 JDBC 3.0을 지원하는 드라이버에서 사용

가능하다. JEUS에서 제공하는 'Session Kill 기능(dba-timeout)' 대신 이

옵션을 사용하기를 권장한다. 이에 관한 자세한 사항은 "DB Session Kill

기능 : DBA 위임 데이터 소스 (DBA Delegation Datasource)"를 참고한

다.

컴포넌트(주로 Stateless 컴포넌트 - 서블릿/JSP, Stateless Session

Bean, MDB)에서 사용한 JDBC 커넥션에 대한 Logging이나 반환 액션

<action-on-connection-leak>

을 설정한다. 설정하지 않았을 경우 기본 동작은 엔진 컨테이너에 설정

한 invocation-manager-action을 따른다.

invocation-manager-action에 대한 설명은 “1.4.4. Invocation Manager”

를 참고한다.

DB와 connection을 맺을 때 login 과정에서의 timeout을 설정한다.(기본

값 : 0, 단위 : sec)

<login-timeout>

주의

data-source-name, service-name, network-protocol, driver-type 등 특정 JDBC 드라이버에 의존적인

프로퍼티들은 Custom 프로퍼티 설정으로 대체하길 권장한다.

데이터 소스 사용자 이름 및 패스워드의 관리

JEUSMain.xml에 각 데이터 소스 사용자 이름(<user>)과 패스워드(<password>)가 설정된다.

JEUS 6 Fix#8부터는 데이터 소스 사용자 이름과 패스워드를 별도의 프로퍼티 파일에서 따로 관리하는 기

능을 제공한다. 프로퍼티 파일의 설정이 JEUSMain.xml의 설정보다 우선하므로 프로퍼티 파일에 대하여

적절히 권한 설정을 하면 JEUS 관리자가 데이터 소스 사용자 이름 및 패스워드를 변경하지 못하도록 제

한할 수 있다.

다음의 옵션으로 프로퍼티 파일의 절대 경로를 설정하면 JEUS는 프로퍼티 파일에 정의된 데이터 소스 사

용자 이름과 패스워드를 가지고 데이터 소스에 대한 Connection Pool을 구성한다.

-Djeus.jdbc.ds-accounts-properties-path

데이터 소스의 구분은 JEUSMain.xml에서와 마찬가지로 데이터 소스 ID(<data-source-id>)를 사용하여야

하므로 데이터 소스 사용자 이름에 대한 프로퍼티 키는 data_source_id.user, 데이터 소스 패스워드에

대한 프로퍼티 키는 data_source_id.password가 된다.

예제 [예 8.1]에 대하여 프로퍼티 파일은 다음과 같이 작성될 수 있으며 JEUS_HOME/config/ds-accounts.prop

erties.template으로 프로퍼티 파일 템플릿을 제공하고 있으니 프로퍼티 파일 작성시 참고한다.

[예 8.2] ds-accounts.properties

datasource1.user=foo

datasource1.password=bar


8.3.3. Custom DB 속성 추가

기본 설정으로 부족할 때 <database> 구성에 Custom 프로퍼티를 추가하여 해당 프로퍼티를 가진 DB 드

라이버를 사용할 수 있다. 각각의 DB 마다 요구하는 프로퍼티와 그 값이 다르므로 각 벤더의 JDBC 드라

이버 매뉴얼에서 필요한 프로퍼티를 찾도록 한다.

다음 예제와 같이 <property> 태그에 다음과 같이 설정한다.

[예 8.3] Custom DB 속성 추가 : <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

<data-source>

<database>

. . . 

<property>

<name>portNumber</name>

<type>java.lang.Integer</type>

<value>1099</value>

</property>

<property>



<value>thin</value>

</property>

</database>

. . .

</data-source>

</resource>

</jeus-system>

다음의 3가지 항목 설정으로 각각의 새로운 속성을 추가할 수 있다.

설명항목

속성의 이름이다.<name>

java.lang.String, 원시 타입(Primitive type)의 래퍼 클래스(예 : java.lang.Integer), ja

va.util.Properties가 올 수 있다.

<type>

속성에 문자열을 설정한다.<value>

위의 예처럼 프로퍼티가 지정이 되면 JEUS는 벤더의 JDBC 드라이버에 setPortNumber라는 메소드를

호출하게 된다. 그러므로 사용자는 각 벤더의 매뉴얼 등을 참고하여 속성을 알맞게 설정하도록 한다.

위에서 설명된 데이터 소스를 적절히 구성해 주었다면, JEUS를 재시작해야 데이터 소스를 애플리케이션

에서 사용할 수 있다.


8.3.4. Connection Pool 설정

각 데이터 소스는 향상된 성능을 위하여 Connection Pool 설정을 할 수 있다. 이는 JEUSMain.xml의

<database> 태그 아래 <connection-pool>을 사용하여 구성된다.

다음은 Connection Pool을 설정한 JEUSMain.xml 예제이다.

[예 8.4] Connection Pool 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

<data-source>

<database>

. . . 

<connection-pool>

<pooling>

<min>2</min>

<max>20</max>


</pooling>

<wait-free-connection>

<enable-wait>true</enable-wait>

<wait-time>60000</wait-time>

</wait-free-connection>

<max-use-count>30</max-use-count>



<check-query>SELECT 1 FROM DUAL</check-query>

<non-validation-interval>5000</non-validation-interval>

<check-query-period>1000000</check-query-period>

<destroy-policy-on-check-query>

AllConnections

</destroy-policy-on-check-query>

<stmt-caching-size>10</stmt-caching-size>

<connection-trace>

<enabled>true</enabled>

</connection-trace>

<use-sql-trace>true</use-sql-trace>



<keep-connection-handle-open>false</keep-connection-handle-open>

</connection-pool>

</database>

. . .


</data-source>

</resource>

</jeus-system>

다음은 설정된 태그에 대한 설명이다.

● <pooling>

– Connection Pool 옵션들은 <connection-pool> 태그의 하위에서 <pooling> 태그로 묶인다.

– 해당 옵션들은 다음과 같다.

설명항목

Cache를 위한 DB 커넥션들의 최소값(초기값)이다.<min>

Cache를 위한 DB 커넥션들의 최대값이다.<max>

초기화된 후 커넥션 수를 늘릴 상황이 되면 커넥션이 이 값만큼 증가하게 된다.<step>

여기 설정 된 period 값에 한 번씩 커넥션 수를 조정한다. 여기서 조정 대상이 되는 커

넥션들은 idle 커넥션이 된다.

<period>

만약 현재 커넥션이 앞서 지정 된 min 값보다 작을 경우에는 Idle 커넥션 수를 min값

만큼 늘려주게 되며, 그 반대의 경우 Idle 커넥션 수를 줄여 min값에 맞춰주게 된다.

만약 Idle 커넥션이 없을 경우에는 min 값만큼 줄이는 작업은 하지 않는다. 원활한 DB

작업을 위하여 이 값은 충분히 잡아주도록 한다.(기본값: 30분, 단위:msec)

● <wait-free-connection>

– Pool 안에 Idle 커넥션이 있지 않을 경우 사용된다. 이 태그 역시 <connection-pool>의 하위에서 설정

된다.

설명항목

이 태그는 Pool안에 이용 가능한 커넥션이 없고 현재 커넥션들이 이미 최대값에 도달

했을 때 DB 커넥션 요청을 처리하는 방법을 결정한다.

<enable-wait>

만약 true라면 시스템은 이용 가능한 커넥션을 얻기 위해 대기한다. 만약 대기 후에도

커넥션을 가져오지 못한다면 exception이 발생한다. 값이 false일 경우에는 커넥션을

새로 만들어서 애플리케이션에 제공하고 애플리케이션이 이를 반납하면 Pooling하지

않고 닫아서 버린다. 이렇게 한번 쓰고 버린다는 의미로 JEUS에서 'disposable 커넥

션'이라고 한다.

이 태그는 <enable-wait>가 true일 때만 유효하다. 이것은 사용자가 커넥션을 위해 대

기하는 시간을 나타낸다. 만약 어떠한 커넥션도 사용자가 이 시간 동안 대기해서 이용

할 수 없을 때는 시스템은 사용자에게 Exception을 출력한다.(단위: msec)

<wait-time>

● <delegation-datasource>

– 현재의 XA DataSource의 전역/지역 트랜잭션을 NonXA-DataSource로 전송할 때 사용한다.


– 데이터 소스가 XA 또는 로컬 XA일 때 트랜잭션으로 묶이지 않는 상황에서 커넥션을 얻어올 경우, 여

기에 설정 된 데이터 소스에서 커넥션을 가져온다. 그러므로 이 태그에 해당하는 값은 ConnectionPool

DataSource타입으로 설정 된 데이터 소스의 export name이어야 한다. 자세한 내용은 "DB Session

Kill 기능 : DBA 위임 데이터 소스 (DBA Delegation Datasource)"부분을 참고한다.

● <max-use-count>

– 한 개의 커넥션에 대해서 설정된 숫자만큼 사용하게 되면 해당 커넥션을 버리고 새로운 커넥션을 맺

게 된다.

– 기본값은 '0'이며 이는 커넥션들을 교체하지 않겠다는 의미이다.

● <delegation-dba>

– DBA 권한을 갖는 특별한 데이터 소스를 지정한다.

– 설정값은 지정 데이터 소스의 export name을 사용한다. 이 기능은 DB에서 기능을 제공해야 한다.

(예 : Tibero,Oracle, Sybase) 지원 여부는 각 벤더의 매뉴얼등을 참고하도록 한다. 자세한 내용은 "DB

Session Kill 기능 : DBA 위임 데이터 소스 (DBA Delegation Datasource)"부분을 참고한다.

● <dba-timeout>(deprecate)

– ConnectionPool에서 얻은 Connection을 여기에서 지정한 시간이 지난 후에도 반납하지 않으면 dele

gation-dba에서 설정된 DataSource를 통해 session kill 명령을 보내서 해당 커넥션과 DB 세션을 강

제로 닫아준다. 하지만 이 기능은 꽤 위험하고 대체 기능이 있기 때문에 사용하기를 권장하지 않는다.

자세한 내용은 "DB Session Kill 기능 : DBA 위임 데이터 소스 (DBA Delegation Datasource)"부분을

참고한다.

– 기본값: 무제한(-1), 단위: millisecond

● <check-query>

– 애플리케이션이 getConnection할 때 JDBC 커넥션에 문제가 있는지 체크할 때 사용된다.

– JDBC 커넥션의 내부적인 에러로 인한 끊김, 방화벽에 의한 소켓 끊김 현상 등을 체크할 때 유용하다.

체크가 실패하면 물리적 커넥션을 새로 만들어서 그에 대한 핸들을 애플리케이션으로 리턴한다. 클

러스터 데이터 소스를 사용하는 경우, 데이터 소스의 상태 체크에 이용하므로 반드시 설정해야 한다

(예 : SELECT 1 FROM DUAL).

● <check-query-timeout>

– check-query를 했을 때 DB 상황에 따라서 JDBC 드라이버가 응답을 못 받고 계속 기다릴 수 있다. 이

런 문제를 방지하기 위하여 JDBC 스펙에 정의된 query timeout 설정을 사용하여 타임아웃을 줄 수

있다.

– 타임아웃이 되면 커넥션이 무효한 것으로 판단한다. 참고로 이를 제대로 지원하지 않는 드라이버가

있을 수 있다.

● <non-validation-interval>

– check-query를 수행할 때의 시각과 맨 마지막에 점검한 시각과의 차이가 이 Interval 내에 있다면

check-query를 수행하지 않는다.


– 커넥션 요청이 빈번할 경우 check-query가 너무 잦아져서 오버헤드를 줄 수 있는데 이 값을 적절하게

설정하면 체크 횟수를 줄일 수 있다.

● <check-query-period>

– JDBC 커넥션을 일정 시간마다 체크하여 문제가 있는 커넥션을 닫아준다.

– 이 기능을 사용하려면 check-query가 반드시 설정되어야 한다. 클러스터 데이터 소스를 사용하는 경

우, 데이터 소스의 상태 체크에 이용하므로 반드시 설정해야 한다.(단위 : msec) 이 값은 충분히 크게

지정한다.

● <check-query-retrial-count>

– check-query는 기본적으로 한번만 수행하지만 이것이 부족하다고 판단될 경우에는 이 설정을 통해서

체크 횟수를 늘릴 수가 있다.

● <check-query-class>

– Check-Query기능의 확장을 위해 존재한다.

– 이 태그에는 jeus.jdbc.connectionpool.JEUSConnectionChecker를 구현한 클래스의 full name을 입

력한다. 그렇게 할 경우 JEUS는 사용자가 지정한 클래스를 이용하여 Check-Query를 실행한다. 자세

한 내용은 "커넥션 점검(Connection Validation or Check Query)"을 참고한다.

● <destroy-policy-on-check-query>

– JDBC 커넥션 유효성 체크가 실패했을 경우 해당 Connection Pool의 커넥션들을 어떻게 할지 정책을

결정하는 옵션이다.

– 정책의 경우 'FailedConnectionOnly'와 'AllConnections'가 있다. 자세한 내용은 "커넥션 점검(Connection

Validation or Check Query)"을 참고한다.

● <stmt-caching-size>

– PreparedStatement 객체를 얼마나 Cache할 지 지정한다. 기본값으로는 이 기능을 사용하지 않는다.

– Oracle 9i 이후 버전에서는 사용하지 않도록 한다. 다른 DBMS에서는 시스템 리소스의 낭비를 줄임으

로써 성능 향상을 가져 올 수 있다.

● <stmt-fetch-size>

– 여기에 지정된 값은 직접 하부 DB의 커넥션 객체에 저장 되는 값으로서 커넥션의 row fetch 값을 지

정한다.

– 현재 JEUS에서는 Oracle과 Sybase에서 이 기능을 제공한다.

● <connection-trace>

– 커넥션이 보여줄 수 있는 정보들을 생성해 둘 것인지 설정하는 옵션이다.

– 현재는 invocation manager를 설정했을 때 또는 jeusadmin의 dsconinfo 명령을 통해서 현재 커넥션

을 사용하고 있는 애플리케이션을 Thread Stack으로 확인할 수 있는 기능을 제공한다.


설명하위 항목

이 태그는 connection trace 기능을 on/off 하는 옵션을 나타낸다.<enabled>

● <keep-connection-handle-open>

– 물리적 커넥션을 Pooling하는 동안 커넥션 핸들(또는 논리적 커넥션)을 항상 열어두고 사용하고자 할

때 필요한 옵션이다.

– DB2 Universal Driver에서 XA 데이터 소스를 사용할 경우에 이 옵션을 true로 설정하길 권장한다.

IBM DB2에서 제공하는 Universal Driver(JCC) type 4는 2007년 11월에 XA 데이터 소스에 문제가 있

음을 확인하였다. 여러 스레드에서 서로 다른 물리적 커넥션을 가져가서 핸들(또는 논리적 커넥션)을

get(open) & close 하면서 사용하다 보면 드라이버 내부적으로 무한루프에 빠진다. 이때 Thread Stack

Dump를 확인하면 내부적으로 같은 Vector(java.util.Vector)를 공유해서 사용하고 있는데 한 스레드

는 Vector에 대한 Lock을 설정하고 'Runnable'인 상태이고 다른 스레드들은 그 Lock을 기다리게 된다.

DB2 내부 로직을 알 수 없기에 정확한 원인은 알 수 없지만 테스트 결과 커넥션 핸들을 항상 열어두

면 문제가 발생하지 않는 것을 확인하였다. 커넥션 핸들을 항상 열어두면 내부 공유 Vector에 접근하

는 일이 맨 처음 생성할 때와 물리적 커넥션을 닫을 때 외에는 없기 때문이다. 이를 설정하는 방법은

JEUS 6 fix#2부터 추가되는 옵션인 <keep-connection- handle-open>을 true로 설정한다.

DB2 드라이버 3.53.95부터 버그가 수정되어서 <keep-connection- handle-open>을 사용하지 않아도

제대로 동작한다. 이에 대한 IBM 공식 버그 리포트 넘버는 APAR IZ41181이며, DB2 9.5 Fixpak 4 문

서에서 확인할 수 있다. 실제로는 JEUS와 LIG 손해보험을 통해서 문제가 제기되었지만 WebLogic

9.2에서 문제가 발생한 것처럼 되어 있다.

● <init-sql>

– 커넥션이 생성된 후 가장 처음으로 수행해야 하는 SQL이 있을 때 설정해서 사용한다.

– keep-connection-handle-open 기능을 사용하면 init-sql을 수행할 때 사용했던 connection-handle을

계속 열어두고 사용한다.

● <use-sql-trace>

– 애플리케이션이 사용한 SQL문을 로그에 남기거나 현재 커넥션에서 수행되고 있는 SQL을 확인할 수

있는 기능이다.

주의

이 기능을 사용하게 되면 항상 JDBC Statement 객체에 대한 래퍼를 사용하게 되므로 JDBC 드라이

버의 Statement 객체를 캐스팅해서 사용할 경우에는 이 기능을 사용할 수 없다.

커넥션 점검(Connection Validation or Check Query)

애플리케이션이 JDBC 커넥션 요청을 했을 때(getConnection method) 특정 select 쿼리를 보내서 커넥션

의 상태를 점검(validation)하는 기능이다. JDBC 커넥션의 내부적인 에러로 인한 끊김, 방화벽에 의한 소

켓 끊김 현상 등을 체크할 때 유용하다. 점검이 실패하면 물리적 커넥션을 새로 생성하여 그에 대한 핸들


을 애플리케이션으로 리턴한다. 만약 RAC를 위한 데이터 소스 클러스터링을 사용하는 경우 이것을 반드

시 설정해야 한다.

● <check-query>

Check-query 기능은 크게 2가지로 설정할 수 있다.

– 단순히 설정상의 <check-query> 태그에 쿼리문을 넣는 방법

– <check-query-class> 태그를 이용하여 기능을 확장

Check-query를 위한 Query문은 DB에 업데이트를 하는 명령이 아닌 단순히 쿼리만을 위한 명령어를 넣

어야 한다. 그렇지 않을 경우 Check-query를 위해 DB Lock을 설정하기 때문에 이후 업데이트를 위한

작업들이 원활히 수행되지 않을 수도 있다.

[예 8.5] <check-query> 설정

<check-query>SELECT 1 FROM dual</check-query>

● <check-query-timeout>

Check-query를 수행했을 때 DB 서버가 응답이 없어 드라이버가 계속 기다리는 상황이 발생할 수 있다.

이런 경우를 피하기 위해 Check-query에 대해서 타임아웃을 설정할 수 있다. 이것은 JDBC에서 제공하

는 'statement query timeout' 기능을 이용하는 것이다. 설정단위는 ms이며, 1000 ms보다 적을 경우 결

국 0이 설정되므로 주의한다.

[예 8.6] <check-query-timeout> 설정

<check-query-timeout>15000</check-query-timeout>

● <non-validation-interval>

Check-query가 너무 잦아져서 오버헤드가 발생하는 경우 <non-validation-interval> 설정한다. 이는

Check-query를 수행할 때의 시각과 맨 마지막에 커넥션을 사용한 시각과의 차이가 설정한 Interval 내

라면 Check-query를 하지 않도록 하는 설정이다.

예를 들어, Non-Validation-Interval을 5초(5000 ms)라고 설정했을 때, 어떤 커넥션을 Pool에서 꺼내서

마지막에 사용했던 시간이 아직 5초가 지나지 않았다면 그 커넥션이 유효하다고 가정하고 Check-query

를 수행하지 않는 것이다.

[예 8.7] <non-validation-interval> 설정


● <destroy-policy-on-check-query>

사용자는 Check-query가 실패했을 때 해당 Connection Pool에 있는 나머지 커넥션들에 대한 destroy

정책을 결정할 수 있다. 정책은 다음과 같다.

설명구분

Check-query가 실패한 커넥션만 버린다.(기본값)FailedConnectionOnly


설명구분

나머지 커넥션들도 모두 버린다. 만약 정책을 'AllConnections'로 했을 경

우에는 Check-query가 실패하자마자 바로 커넥션들을 버리는 것이 아니라

AllConnections

한 번 더 커넥션을 Pool에서 꺼내서 Check-query를 시도한다. 그마저도 실

패하면 비로소 Pool에 있는 모든 커넥션들을 버린다.

[예 8.8] check-query 실패시 Pool에 있는 커넥션에 대한 destroy 정책 설정

<destroy-policy-on-check-query>AllConnections</destroy-policy-on-check-query>

● <check-query-retrial-count>

Check-query를 추가적으로 더 하도록 설정하고 싶을 경우에는 <check-query-retrial-count>를 이용해서

설정할 수 있다.

Check-query 클래스는 Check-query 기능을 사용자가 확장할 수 있도록 한다. 응용 프로그램 개발자나 사

용자는 위에서 제시한 jeus.jdbc.connectionpool.JEUSConnectionChecker interface를 구현함으로써 기능

의 확장을 도모할 수 있다.

[예 8.9] jeus.jdbc.connectionpool.JEUSConnectionChecker

public interface JEUSConnectionChecker {

void checkConnection(Connection vcon) throws SQLException;

void setQueryString(String query);

void setQueryTimeout(int timeout);

}

설명메소드

이 메소드는 실제 Check-query 작업을 수행할 때 불려진다. 그러므로 개발자

는 이 메소드에 자신이 Check-query시 실행하고 싶은 내용들을 구현하여 입

력한다.

checkConnection()

만약 <check-query> 태그에 Query문이 지정되어 있는 상태라면, JEUS는 이

메소드를 호출한다. 물론 인자로는 <check-query> 태그에 지정된 Query문이

들어가게 된다.

setQueryString()

만약 <check-query-timeout>이 지정되어 있는 상태라면, JEUS는 이 메소드

를 호출한다.

setQueryTimeout()

만약 Check-query 클래스가 지정이 되지 않은 상태라면, JEUS는 지정된 Query문만을 이용하여 Check-

query를 수행한다. 즉 Check-query 클래스의 사용은 선택을 할 수 있으며, 단순히 Query문을 이용하는 것

이 아닌 특별한 작업이 필요한 경우에만 사용하도록 한다.


SQL Trace

커넥션별로 사용하고 있는 SQL문을 조회하는 기능이다. 시스템 로그를 통해서 SQL history를 조회할 수

있고, jeusadmin을 통해서 커넥션별로 현재 수행되고 있는 SQL을 확인할 수 있다. 서버 로그 상에는

jeus.jdbc.sql 로거의 레벨을 FINE으로 설정할 경우 보이게 된다. 그리고 이 기능을 사용할 경우 JDBC 드

라이버의 Statement 객체를 항상 wrapping하게 되므로 JDBC 드라이버의 Statement 객체를 캐스팅해서

사용하는 애플리케이션은 이 기능을 사용할 수 없다.

Statement Caching

...

Connection conn = dataSource.getConnection();

PreparedStatement stmt = conn.prepareStatement(sql);

....

stmt.close();

conn.close();

....

PreparedStatement는 미리 SQL을 Parsing해놓은 인스턴스를 애플리케이션 입장에서 계속 재활용해서

사용할 수 있으므로 매번 드라이버가 SQL을 Parsing하기 위해 들이는 오버헤드를 줄일 수 있다. 그런데

이러한 PreparedStatement 역시 커넥션을 새로 얻을 때마다 SQL Parsing 작업을 해야 하므로 커넥션 요

청(getConnection & close)이 빈번하게 이뤄지는 경우에는 PreparedStatement 인스턴스를 생성하는 것

역시 큰 오버헤드가 될 수 있다. 따라서 JEUS에서는 이런 오버헤드를 줄이기 위해 Statement Caching 기

능을 제공한다.

이것을 사용하면 물리적 커넥션별로 SQL 문장을 키로 하여 PreparedStatement 객체를 저장해놓고 애플

리케이션이 PreparedStatement를 요청할 경우에 파라미터로 넘어온 SQL을 보고 미리 생성된 것이 있으

면 그것을 리턴한다.

그런데 커넥션 인스턴스에서 PreparedStatement를 생성하기 때문에 그 커넥션 인스턴스를 닫아버리면

(close) 해당 PreparedStatement 인스턴스 역시 무효로(invalid) 된다. 따라서 애플리케이션이 커넥션을 닫

았다고 하더라도 실제로 WAS에서는 이 커넥션을 계속 열어둔 채로 재활용하도록 되어 있다. 그래야만

PreparedStatement 인스턴스를 계속 재활용할 수 있기 때문이다.

주의

애플리케이션은 Statement Caching의 제약사항을 반드시 숙지해야 한다. 즉, 커넥션을 항상 열어둔

채로 사용하기 때문에 커넥션을 닫았을 때 드라이버가 해주는 클리어 작업이 이뤄지지 않는다. 예를

들어 Oracle JDBC 드라이버의 경우, auto-commit을 false로 해놓고 사용하다가 Commit이나 Rollback

을 하지 않고 커넥션을 닫으면 무조건 Commit을 하도록 되어 있는데 이런 처리가 되지 않는다는 것

이다. keep-connection-handle-open 옵션 또한 같은 제약사항이 있으므로 주의한다.


위임 데이터 소스

일반적으로 XA 데이터 소스가 사용 되면, 대부분 트랜잭션으로 묶여 작업이 이루어진다. 하지만 일부의

경우에는 트랜잭션이 시작되기 전이나, 끝난 후에 커넥션을 가져다 사용하는 경우가 있을 수 있다. 이런

상황에서는 트랜잭션과 무관하게 커넥션이 사용되므로 Connection Pool 형식의 데이터 소스에서 가져온

커넥션과 동작에 있어 아무런 차이가 없게 된다.

그런데 Oracle, DB2 등의 JDBC 드라이버에서는 XA 커넥션을 트랜잭션 없이 사용도 하고 트랜잭션에 연

동도 하면서 사용하다 보면 XA를 시작할 수 없는 예외가 발생한다. 정확한 원인은 알 수 없기 때문에 이를

피해 가기 위해서 위임 데이터 소스를 사용할 수 있다.

위임 데이터 소스(Delegation Datasource)는 XA 형식으로 지정된 데이터 소스가 트랜잭션과 무관한 곳에

서 커넥션 요청을 받을 경우 이용하게 되는 데이터 소스이다. 이 상황에서 사용자가 커넥션 요청을 할 경

우 XA 데이터 소스는 위임 데이터 소스로 지정된 Connection Pool 데이터 소스에서 커넥션을 가져와 사

용자에게 넘겨주게 된다.

이 기능을 사용하기 위해서는 우선 XA 데이터 소스와 같은 DB에 대한 Connection Pool 데이터 소스를 지

정한다. 그리고 <delegation-datasource> 태그 내부에 설정한 Connection Pool 데이터 소스의 JNDI 이

름을 입력한다.

DB Session Kill 기능 : DBA 위임 데이터 소스 (DBA Delegation Datasource)

<delegation-datasource>, <dba-timeout>에서 설명한 것처럼 DBA 위임 데이터 소스는 커넥션에 대응하

는 DB 세션을 강제로 정리해야 할 필요가 있을 때 사용한다. ConnectionPool에서 커넥션을 얻어간 뒤 오

랜 시간동안 Pool로 반납되지 않으면 해당 커넥션이 DB에 부하를 주거나 장애를 일으킬 것으로 판단하고

강제로 DB를 정리를 하고자 사용하던 기능이다.

JEUS 6 Fix#6에서는 Webadmin을 통해서 DB 커넥션 강제 정리 명령을 내릴 때도 DBA 위임 데이터 소스

가 설정되어 있다면 이를 이용해서 DB에 Session Kill명령을 내리도록 하였다. 기본적으로 이 기능은 DB

에 직접 operation을 하기 때문에 사용할 때 주의가 필요하지만 다음의 예제에서 <dba-timeout>을 설정

하면 어떻게 작동하는지 간략하게 설명한다.

우선 사용하는 데이터 소스 외에 Connection Pool 형식의 새로운 데이터 소스를 설정한다. 그 데이터 소스

이름이 DBKiller라고 한다면 사용하고 있는 데이터 소스에 다음과 같이 설정한다.

[예 8.10] <dba-timeout> 설정

.....

<connection-pool>

<delegation-dba>DBKiller</delegation-dba>

<dba-timeout>60000</dba-timeout>

</connection-pool>

.....

만약 현재 사용하는 데이터 소스에서 얻어진 커넥션이 <dba-timeout> 태그에 지정 된 60초(단위 : ms) 내

에 반납이 되지 않으면, JEUS JDBC는 DBKiller 데이터 소스에 반납되지 않은 커넥션의 세션 ID를 죽이라

는 kill 명령을 내린다. 그렇게 되면 DBKiller 데이터 소스는 해당 커넥션을 강제로 닫아주게 되게 된다. 하


지만 응용 프로그램이 명시적으로 close 명령을 내리지 않으면 해당 커넥션은 active인 상태로 남아있게

된다. close를 호출하면 커넥션을 버리고 새로 커넥션을 맺어서 Pool에 넣어둔다.

이 기능을 사용하기 위해서는 DB가 이 기능을 지원해야 한다. JEUS에서는 단순히 해당 DB에 세션 제거

를 요청하는 Query를 요청하고, DB가 해당 Query를 받아 동작을 수행한다. 자세한 내용은 DB 벤더에서

제공된 매뉴얼을 참고하여 기능의 지원 여부를 따져보도록 한다. 또한 DBA 위임 데이터 소스는 실제 DBA

대상이 되는 데이터 소스와 같은 DB에 설정이 되어있어야 한다.

주의

1. 이 기능은 JDBC 2.0 이하 드라이버에서 select query 등이 너무 오래 걸릴 때 그것을 끊어줄 방법

이 없어서 사용한 방법이다. 그러나 JDBC 3.0 또는 그 이상의 버전을 구현한 드라이버는 statement

query timeout 옵션을 제공하므로 더이상 Session Kill 기능을 사용할 필요가 없다. 대신

<database><stmt-query-timeout> 설정의 사용을 권장한다.

2. XA 데이터 소스에 설정하면 안 된다. 왜냐하면 XA가 정상적으로 진행하는 도중에 Session Kill이

일어날 수 있으며, 커넥션 공유 상황에서는 Session Kill이 발생한 이후에 제대로 Rollback이 되지 않

을 수 있기 때문이다. 따라서 XA 데이터 소스에는 statement query timeout을 사용해야 하며, 추가적

으로 컨테이너 설정에 트랜잭션 타임아웃을 적절하게 설정하여 사용하길 권장한다.

8.3.5. 클러스터 데이터 소스 설정

JEUS 차원에서 RAC 인스턴스 간의 장애 복구(failover and failback)를 제공하기 위해서 클러스터 데이터

소스를 설정할 수 있다. 이 설정은 <resource> <data-source> <cluster-ds> 태그를 사용해서 설정한다.

다음은 클러스터 데이터 소스 설정에 대한 예제이다.

[예 8.11] 클러스터 데이터 소스 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

<data-source>

<database>

<export-name>RAC1</export-name>

. . .

</database>

<database>


. . .

</database>

. . .

<cluster-ds>

<export-name>RAC</export-name>

<data-source>RAC1</data-source>


</cluster-ds>


</data-source>

</resource>

</jeus-system>


설명태그

클러스터 데이터 소스의 ID를 설정한다.<data-source-id>

클러스터 데이터 소스의 JNDI 이름을 설정한다.<export-name>

클러스터 데이터 소스를 사용할 엔진 컨테이너 이름을 설정한다.<data-source-target>

설정하지 않으면 노드에 속한 모든 엔진 컨테이너에서 사용할 수 있다.

클러스터 데이터 소스로부터 커넥션을 얻을 때, 클러스터 데이터 소스에 참

여하고 있는 특정 데이터 소스 선택에 대한 정책을 정의하는 클래스의 이름

<data-source-selector>

(Fully Qualified Class Name)을 설정한다. 자세한 사용법은 "데이터 소스 셀

렉터 사용하기"에서 설명한다.

getConnection을 요청하는 경우 Round-Robin 방식으로 데이터 소스를 선택

하고 선택한 데이터 소스에서 커넥션을 얻어 리턴한다.

<load-balance>

JEUS 6 Fix#7에 추가된 기능이다.

failback 기능을 사용할 것인지 선택하는 옵션이다. 이전에는 failover만을 지

원했기 때문에 호환성을 위해서 만든 옵션이다.(기본값: true)

<use-failback>

true이면 클러스터 데이터 소스에 참여하는 모든 데이터 소스의 커넥션을 미

리 연결해 놓는다. 이렇게 될 경우 failover 성능은 향상될 수 있으나, 반대로

시스템 리소스가 많이 이용된다는 단점이 있다.(기본값 : false)

<is-pre-conn>

클러스터 데이터 소스에 포함되는 데이터 소스의 export name을 입력한다.

리스트의 첫 번째가 주 RAC 인스턴스가 되고, 이것이 Down되면 다음 인스

<data-source>

턴스가 선택된다. 다음의 설정 예제의 경우 처음에는 RAC1 데이터 소스에서

커넥션을 가져오고 커넥션을 가져오는 도중 Exception이 발생할 경우(Wait

timeout인 경우는 제외) RAC2 데이터 소스를 사용한다.

클러스터 데이터 소스에 참여하는 데이터 소스의 설정

JEUS 6 fix#3부터는 자동으로 Failback을 해주는 기능이 포함된다.

클러스터 데이터 소스에서 Failback을 하기 위해서는, 참여하는 모든 데이터 소스에 반드시 <check-query>

및 <check-query-period>를 설정해야 한다.

예제에서 주 데이터 소스는 RAC1이고 백업 데이터 소스가 RAC2이다. 만약 RAC1이 죽었거나 문제가 생

겼을 경우에는, 애플리케이션이 커넥션을 가져갈 때(getConnection) <check-query>에 의해 이를 감지하

게 되며 Failover를 통해서 RAC2 데이터 소스를 사용하게 된다. 그리고 RAC1 데이터 소스가 살아났는지


<check-query-period>에 설정한 주기마다 체크한다. RAC1 데이터 소스가 살아난 후부터는 모든 커넥션

요청이 자동으로 RAC1 데이터 소스로 가게 된다.

만약 예전처럼(JEUS 6 fix#2 이하) Failover만을 사용해야 할 경우에는 <cluster-ds><use-failback>을 false

로 할 수 있다.

참고

수동으로 Failback 명령을 내릴 수 있는데 이에 대해서는 "JEUS Reference Book"에서 controlcds

명령을 참고한다.

<check-query>가 실패하는 경우 Pool에 있는 커넥션에 대한 destroy 정책을 AllConnections로 설정한다.

그렇지 않으면 만약 RAC1이 죽고 RAC2로 Failover 되었을 경우 RAC1에는 이미 끊어진 커넥션들이 Pool

에 계속 남아있게 된다. 물론 주기적인 <check-query>에 의해서 정리가 되지만 Failover가 이뤄지는 시점

에 끊어진 커넥션들이 정리가 되는 것이 좀 더 바람직하기 때문이다.

[예 8.12] 자동으로 Failback 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

<data-source>

<database>


. . .

<check-query>select 1 from dual</check-query>



AllConnections


</database>

<database>


. . .

<check-query>select 1 from dual</check-query>



AllConnections


</database>

. . .

<cluster-ds>




</cluster-ds>

</data-source>


</resource>

</jeus-system>

데이터 소스 셀렉터 사용하기

JEUS 6 fix#8부터는 클러스터 데이터 소스로부터 커넥션을 얻을 때, 클러스터 데이터 소스에 참여하고 있

는 특정 데이터 소스 선택에 대한 정책을 사용자나 개발자가 직접 정의할 수 있다. jeus.jdbc.helper.Data

SourceSelector 추상 클래스를 구현함으로써 정책을 정의하고 <data-source-selector> 설정에 구현 클래

스의 이름(Fully Qualified Class Name)을 설정한다.

jeus.jdbc.helper.DataSourceSelector API는 다음과 같이 정의되어 있다.

[예 8.13] jeus.jdbc.helper.DataSourceSelector

public abstract class DataSourceSelector {

public List<String> getDataSourceList() {...}

public int getDataSourceListSize() {...}

public int getDataSourceIndex(String dataSourceId) {...}

public String getDataSourceId(int index) {...}

public abstract int selectDataSource();

}

● public List<String> getDataSourceList()

– jeus.jdbc.helper.DataSourceSelector에 구현되어 있다.

– 클러스터 데이터 소스에 참여하고 있는 데이터 소스들의 <data-source-id> 리스트를 얻는다.

● public int getDataSourceSize()


– 클러스터 데이터 소스에 참여하고 있는 데이터 소스들의 총 개수를 얻는다.

● public int getDataSourceIndex(dataSourceId)


– 클러스터 데이터 소스에 참여하고 있는 데이터 소스의 <data-source-id>를 인자로 받아 그것의 인덱

스를 얻는다. 인덱스는 데이터 소스들이 등록된 순서에 따르며 0부터 시작한다.

● public String getDataSourceId(int index)



– 클러스터 데이터 소스에 참여하고 있는 데이터 소스의 인덱스를 인자로 받아서 그것의 <data-source-

id>를 얻는다. 인덱스는 데이터 소스들이 등록된 순서에 따르며 0부터 시작한다.

● public abstract int selectDataSource()

– 데이터 소스 선택에 대한 정책 정의를 위해 구현해야 하는 메소드이다.

– 리턴값은 정의된 정책을 통하여 선택된 데이터 소스의 인덱스가 되어야 한다. 대부분의 환경에서 클

러스터 데이터 소스로부터 커넥션을 얻을 때는 다수의 요청 스레드들이 동시에 접근할 것이므로 정

책을 정의할 때는 대체로 동기화에 대한 고려가 필요하며 그것은 구현자의 몫이다.

위의 API를 바탕으로 다음과 같은 customized DataSourceSelector 구현이 가능하다. 참고로 이 Data

SourceSelector 구현체는 클러스터 데이터 소스에 참여하는 데이터 소스들을 5회 주기로 번갈아가며 선

택하는 정책을 정의하고 있으며 동기화를 고려하여 selectDataSource 메소드를 synchronized로 구현하

였다.

[예 8.14] foo.bar.SampleDataSourceSelector

package foo.bar;

import jeus.jdbc.helper.DataSourceSelector

public class SampleDataSourceSelector extends DataSourceSelector{

int counter = 0;

int dataSourceIndex = 0;

@Override

public synchronized int selectDataSource() {

try {

String dataSourceId = getDataSourceId(dataSourceIndex);

System.out.println(dataSourceId + "selected.");

return dataSourceIndex;

} finally {

if((++counter & 0x7fffffff) % 5 == 0)

if(++dataSourceIndex == getDataSourceListSize())

dataSourceIndex = 0;

}

}

}


클러스터 데이터 소스 설정은 다음과 같이 할 수 있다.

[예 8.15] <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

<data-source>

. . .

<cluster-ds>


<data-source-selector>foo.bar.SampleDataSourceSelector</data-source-selector>



</cluster-ds>

</data-source>

</resource>

</jeus-system>

데이터 소스 셀렉터를 사용할 경우 <load-balance> 설정은 아무런 기능을 하지 않으며 Failover와 Failback

을 무조건 시도한다. Failover는 구현한 데이터 소스 셀렉터를 통하여 최초 선택된 데이터 소스 다음 인덱

스의 데이터 소스를 시작으로 한 번만 rounding하는 방식으로 이루어진다. Failback은 <use-failback> 설

정할 때와 유사한 방식으로 이루어지므로 클러스터 데이터 소스에 참여하는 데이터 소스들에 대하여

<check-query>와 <check-qeury-period> 설정을 반드시 해야 한다.

8.4. DB Connection Pool의 제어 및 모니터링사용자는 DB Connection Pool을 실시간으로 제어하기 위해서 콘솔 툴인 jeusadmin이나 WebAdmin을 사

용할 수 있다. WebAdmin에 대한 설명은 "JEUS WebAdmin 안내서"를 참조한다.

JEUS 6 Fix#7 이후로는 각 명령에서 사용하는 데이터 소스 지칭 인자는 데이터 소스의 JNDI Export 이름

이 아니라 데이터 소스의 ID임을 유념해야 한다. jeusadmin의 ‘help -g jdbc’명령어를 사용하여 jdbc관련

명령어들의 정보를 확인할 수 있다.

8.4.1. DB Connection Pool의 제어

JEUS의 주 콘솔 툴인 jeusadmin을 이용하여 DB 관련 설정 및 동작을 모니터링하거나 제어할 수 있다.

[blah@johan:/opt/jeus/bin] ./jeusadmin johan [options]

위의 명령을 사용하여 JEUS 노드에 접속을 한다. 그 후 몇 가지 Connection Pool 제어 명령을 수행할 수

있다.

● Connection Pool 제어 명령 수행 후의 결과를 확인


Connection Pool 제어 명령 수행 후의 결과를 확인하려면 “8.4.2. DB Connection Pool의 모니터링”을

참고하여 Connection Pool을 모니터링한다.

● Connection Pool을 비활성화하기

다음 명령어는 johan_container1에 설정 되어 있는 'datasource1'이라 명명된 Connection Pool을 불능

상태로 만들 때 사용된다.

johan>disableds -con johan_container1 datasource1

● Connection Pool을 활성화하기

Pool을 활성화하려면 다음의 명령어를 적용한다.

johan>enableds -con johan_container1 datasource1

● Connection Pool 생성

jeusadmin을 통해서 Connection Pool을 처음 생성하거나 Pool에 있는 커넥션을 모두 비우고 새로운 커

넥션으로 채워넣을 수도 있다.

처음 생성할 경우에는 다음 명령을 실행한다.

johan>createds -con johan_container1 datasource2

-con 옵션을 주지 않으면 모든 엔진 컨테이너의 커넥션을 Pool을 생성한다. 만약 container.name 프로

퍼티가 설정되어 있다면 그 설정으로 지정된 엔진 컨테이너(들)의 Connection Pool(들)만 생성한다.

● Connection Pool 새로 채우기

현재 Pool에 있는 커넥션을 모두 버리고 새로운 커넥션으로 채워넣고 싶다면(DB를 재기동했거나 비정

상적 종료를 해서 Pool에 있는 커넥션들이 모두 의미없는 상태가 된 경우 등) 다음의 명령을 실행한다.

johan>refreshds -con johan_container1 datasource3

엔진 컨테이너에 해당하는 옵션은 createds 명령과 같다.

● DB Connection Pool 설정 테스트

jeusadmin을 통해서 설정 테스트를 할 수도 있다.

johan>testdsconfig datasource1

8.4.2. DB Connection Pool의 모니터링

본 절에서는 jeusadmin으로 Connection Pool을 모니터링하는 방법을 간략하게 설명한다.

참고

WebAdmin에 대한 설명은 "JEUS WebAdmin 안내서"를 참고한다.

JEUS 6 Fix#7 이후로는 각 명령에서 사용하는 데이터 소스 지칭 인자는 데이터 소스의 JNDI Export

이름이 아니라 데이터 소스의 ID임을 유념해야 한다.


● 하나의 엔진 컨테이너에 구성된 JDBC Connection Pool을 모니터링

jeusadmin에서 하나의 엔진 컨테이너에 구성된 JDBC Connection Pool을 모니터링하기 위해서 dsinfo

를 사용한다.

만약 생성된 Connection Pool만 보고 싶다면 다음의 옵션을 설정한다. -k 옵션은 -i 옵션이 반드시 필요

하며 -i 옵션만 지정했을 경우에는 모니터링 정보 출력을 무한히 반복하게 되는데 <Enter>키를 두 번 눌

러서 끝낼 수 있다.

설명옵션

생성된 Connection Pool만을 출력한다. 인자는 없다.- active

몇 번 정보를 출력할지 결정한다.(예 : -k 20)-k

몇 초에 한번씩 정보를 출력할지 결정한다. 인자값의 단위는 초(sec)이다.(예 : -i 1)-i

johan>dsinfo -con johan_container1

다음은 명령의 실행 결과이다.

=========================================================================================

Connection pool information for engine container 'johan_container1'

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

| id | jndi | min | max | act | idle | disp | tot | wait | work |

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

| datasource1 | datasource1 | 10 | 20 | 0 | 10 | 0 | 10 | true | false |

| datasource2 | datasource2 | 10 | 30 | 0 | 0 | 0 | 0 | true | false |

| datasource3 | datasource3 | 10 | 40 | 0 | 10 | 0 | 10 | true | true |

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

disp : disposable connection, tot(total) = act(active) + idle + disp

=========================================================================================

다음은 명령어 실행 결과의 출력되는 항목에 대한 설명이다.

설명항목

Connection Pool에 대응되는 데이터 소스의 ID로 별도로 설정하지 않았으면 jndi 필

드의 값과 같다.

id

Connection Pool에 대응되는 데이터 소스의 JNDI Export name으로 별도로 설정하지

않았으면 ID 필드의 값과 같다.

jndi

Pool 안에서 유지되는 커넥션의 최소 크기이다(항상 이 값으로 유지되지 않을 수 있

으며 리사이즈 주기에 의해 유지됨).

min

Pool 안에서 유지되는 커넥션의 최대 크기이다.max

애플리케이션이 사용하고 있는 커넥션의 수이다.act

현재 Pool에 들어있는 커넥션의 수이다.idle


설명항목

한번 사용하고 버리는 커넥션의 총 개수이다.disp

DB 커넥션의 총 수이다(active + idle+disposable connection).tot

Pool에 커넥션이 비었을 경우, 스레드를 기다리게 할 것인지를 결정한다.wait

"true"일 경우 기다리게 하고, "false"일 경우 Pool과 상관 없는 커넥션을 생성한다.

만약 DB Pool이 활성화 상태이면 "true"이고 비활성화이거나 아직 생성되지 않은 상

태이면 "false"이다.

work

● 데이터 소스별로 현재 커넥션의 상태를 파악

dsconinfo를 사용하여 각각의 데이터 소스별로 현재 커넥션의 상태를 파악하거나 관련 통계를 볼 수 있

다.

dsconinfo 명령은 데이터 소스의 이름을 인자로 받고 해당 Pool에 있는 커넥션들의 정보를 출력한다. 다

음의 옵션을 설정할 수 있다.

설명항목

몇 번 정보를 출력할지 결정한다.(예 : -k 20)-k

몇 초에 한 번씩 정보를 출력할지 결정한다. 인자값의 단위는 초(sec)이다.(예 : -i 1)-i

johan>dsconinfo -con johan_container1 datasource1

다음은 명령의 실행 결과이다.

====================================================================

Connection information list for the engine container[johan_container1]

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

| id | state | state-time(s) | use-count | type |

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

| datasource1-1 | idle | 48.613 | 0 | pooled |










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

====================================================================

다음은 명령어 실행 결과의 출력되는 항목에 대한 설명이다.


설명항목

해당 컨테이너의 데이터 소스 내에서 각 커넥션별로 붙인 고유한 값이다.id

커넥션의 상태를 나타내며 active와 idle로 나뉜다. active일 경우 현재 사용중인 커넥

션을 의미한다.

state

커넥션이 현재 상태로 바뀐 후 지속된 시간을 의미한다. 예를 들어, 'datasource1-1'

커넥션의 경우 유휴(idle) 상태로 약 48초간 있었음을 알 수 있다.

state time

open, close 짝이 몇 번 발생했는지를 의미한다.usecount

Pooling된 커넥션인지 disposable 커넥션인지 구분할 수 있다.type

● 커넥션을 가장 마지막에 사용한 스레드 조회

-t 옵션을 사용하면 커넥션을 가장 마지막에 사용한 스레드의 이름을 알 수 있다.

johan>dsconinfo -con johan_container1 -t datasource1

==============================================================================

Connection information list for the engine container[johan_container1]

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

| id | state | state-time(ms) | use-count | type | thread name |

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

| datasource1-1 | idle | 10000 | 3 | pooled | |

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

| datasource1-2 | active | 1300 | 2 | pooled | http-w1 |

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

==============================================================================

위 테이블에서처럼 상태가 active인 경우에 thread name 정보가 출력된다. datasource1-2 커넥션은 Leak

일 수도 있으므로 http-w1 스레드는 가장 최근에 커넥션을 사용한 스레드이다.

● 하나의 커넥션에 대한 정보 조회

-id 옵션을 통해 하나의 커넥션에 대한 정보를 볼 수 있다.

johan>dsconinfo -con johan_container1 -id datasource1-1 datasource1

===============================================

Connection[datasource1-1] information in the engine container[johan_container1]

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

| state | state-time(ms) | use-count | type |

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

| idle | 506.617 | 0 | pooled |

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

===============================================

-id 옵션에 쓰이는 인자는 dsconinfo 명령어를 통해 나타난 커넥션 목록에서 나타난 ID이다.


예를 들어, datasource1-1 커넥션 ID를 인자로 설정했을 때 state, use count, type 정보가 출력된다. 만

약 데이터 소스에 getConnection Trace 기능을 사용한다면 이 커넥션을 가져간 애플리케이션들의 정보

를 getConnection할 때의 Stack Dump로 확인할 수 있다.

그리고 SQL Trace를 사용한다면 해당 커넥션에서 실행중인 SQL이 무엇인지 확인할 수 있다. 그리고

이때도 -t 옵션이 적용된다.

8.5. JEUS JDBC 프로그래밍구성한 Connection Pool을 사용하여 코드를 작성하는 방법을 설명한다. 본 절은 JDBC 애플리케이션 프

로그래밍 가이드로 활용하기 바란다.

8.5.1. 간단한 JDBC 프로그래밍

다음의 코드는 JEUSMain.xml에 구성된 데이터 소스를 사용하여 커넥션을 얻는 방법에 대해 보여주고 있

다.


DataSource ds = (DataSource) ctx.lookup("ds1");

Connection con = ds.getConnection();

Statement stmt = con.createStatement();

ResultSet rs = stmt.executeQuery("select * from test");

...

...

con.close();

경고

커넥션을 사용한 후에는 반드시 닫아야 한다.

8.5.2. 트랜잭션 프로그래밍 규칙

JEUS는 트랜잭션 프로그래밍을 위한 표준 단계를 정의한다. UserTransaction를 사용하는 모든 애플리케

이션은 표준 단계들을 따라야 한다.

1. 트랜잭션을 시작한다.

2. DB 커넥션을 얻어 온다.

3. 트랜잭션의 나머지를 코딩한다.

경고

만약 다른 트랜잭션 처리를 원한다면 반드시 새로운 커넥션을 다시 얻어야 한다.


8.5.3. JDBC 드라이버의 커넥션 인스턴스를 얻고 싶을 때

JEUS에서는 애플리케이션에 커넥션을 넘겨줄 때 커넥션의 상태 관리를 위하여 래퍼를 사용하게 된다. 그

러나 Oracle의 CLOB, XMLType 등은 해당 JDBC 드라이버의 커넥션 인스턴스를 직접적으로 필요로 하기

때문에 드라이버 내부적으로 클래스 캐스팅을 하다가 ClassCastException이 발생한다. 이는 JEUS 뿐만

아니라 대부분의 WAS 제품에서 발생할 수 있는 문제이며, 애플리케이션에서는 WAS에서 넘어오는 커넥

션이 드라이버의 커넥션 인스턴스일 것이라고 가정하고 구현해서는 안 된다. 하지만 이를 우회적으로 피

할 수 있는 방법이 있다. 애플리케이션에서는 다음과 같은 방법으로 드라이버의 커넥션 인스턴스를 얻을

수 있다.

import java.sql.Connection;

import java.sql.DatabaseMetaData;

....

Connection conn = datasource.getConnection();

DatabaseMetaData metaData = conn.getMetaData();

OracleConnection oraConn = (OracleConnection)metaData.getConnection();

8.5.4. Standalone 클라이언트에서의 Connection Pool

Standalone 클라이언트에서 clientcontainer.jar 또는 jclient.jar를 이용해서 JEUS에 등록된 데이터 소스 정

보를 이용할 수 있다. 클라이언트에서 JEUSMain.xml에 등록한 JNDI 이름으로 데이터 소스를 찾으면 해

당 정보를 클라이언트로 가져와서 로컬 JVM에 Connection Pool을 구성하도록 되어 있다.

이러한 방식은 클라이언트 프로그램에서 JNDI lookup 방식으로 편리하게 데이터베이스에 접근할 수 있다

는 장점이 있다. 하지만 데이터베이스 입장에서는 WAS 이외에 JDBC 드라이버로 접근하는 클라이언트가

늘어나게 되는 것이고, 클라이언트 프로그램이 서버처럼 계속 돌아가는 프로그램이 아니라면 Connection

Pool을 구성하는 것은 불필요한 자원 낭비라고 할 수 있다. 따라서 실제 서비스를 구현할 때는 이 방식을

사용하는 것을 권장하지 않는다.

경고

JEUS 서버에 구성된 Connection Pool에서 커넥션을 가져와서 사용하는 것이 아니다. 만약 그렇게

하고 싶다면 커넥션을 사용하는 로직을 EJB로 구현해서 JEUS에 Deploy하고 EJB를 찾아서(lookup)

사용해야 한다.

8.6. 글로벌 트랜잭션(XA)과 커넥션 공유커넥션 공유(connection sharing)은 같은 트랜잭션 내에서는 하나의 리소스에 대해 항상 하나의 커넥션만

사용하는 것을 보장한다는 개념으로, JCA 표준에 언급되어 있다. JDBC Connection Pool 입장에서의 리

소스는 대부분 데이터베이스(또는 데이터 소스)이다. JEUS의 DB Connection Pool에서는 특별한 설정이


필요없이 기본적으로 XA 데이터 소스에 대해 커넥션 공유를 제공하며 로컬 XA 데이터 소스도 마찬가지

로 제공한다.

ProFrame과 같은 애플리케이션 프레임워크에서는 같은 트랜잭션 내에서 하나의 데이터 소스에 여러 번

getConnection과 close를 반복하게 되는 경우가 많으므로 커넥션 공유를 사용하는 것이 바람직하다. 그

렇지 않으면 하나의 DB에 대해 여러 개의 물리적 커넥션이 트랜잭션에 참여하기 때문에 DB 입장에서는

불필요하게 많은 트랜잭션 Lock을 필요로 하게 되고 이는 트랜잭션 성능에 큰 영향을 미칠 수 있다.

만약 커넥션 공유를 사용하고 싶지 않을 때는 XA 데이터 소스를 사용하는 Java EE 컴포넌트 설정(web.xml,

ejb-jar.xml 등)에 다음과 같이 설정할 수 있다. 참고로 <res-ref-name>에는 보통 JEUSMain.xml에 설정된

데이터 소스의 JNDI 이름을 입력한다.

<resource-ref>

<res-ref-name>jdbc/xads</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-sharing-scope>Unshareable</res-sharing-scope>

</resource-ref>

아무 설정을 하지 않으면 기본적으로 <res-sharing-scope>가 Shareable이기 때문에 서블릿이나 EJB 컴

포넌트에서 항상 커넥션 공유를 사용한다. 단, 로컬 XA 데이터 소스는 항상 커넥션을 공유해야 하기 때문

에 Unshareable로 설정하면 에러(java.sql.SQLException)가 발생하도록 되어 있다.


제9장 트랜잭션 매니저

본 장에서는 JEUS에서의 트랜잭션 매니저와 그 주변 요소들에 대해 설명한다.

9.1. 개요JEUS 트랜잭션 매니저는 Java EE 환경에서 애플리케이션에게 다양한 형태의 트랜잭션 서비스를 제공할

수 있다. JEUS 트랜잭션 매니저는 애플리케이션의 동작에 따라 필요한 서비스를 제공하며, 다양한 리소

스 매니저와의 연결을 제공한다. 또한 애플리케이션은 필요에 따라 트랜잭션의 제어 권한을 매니저에 일

임할 수도 있고, 자신이 직접 갖을 수도 있다. 트랜잭션 매니저는 리소스 매니저, 애플리케이션 등과 함께

트랜잭션 처리를 위한 작업들을 하며, 그 작업에서 중점적인 역할을 담당한다.

엔터프라이즈 시스템에서 트랜잭션 서비스는 리소스에 대한 대용량의 클라이언트 요청을 안전하고 효율

적으로 처리하는데 기본적이고 중요한 서비스이다. 최근에는 리소스의 종류가 다양해지고, 리소스에 대

한 요청 규모가 커짐에 따라, 트랜잭션 매니저는 통일된 인터페이스를 제공하고 더욱 안정적으로 동작할

필요성이 생겼다.

JEUS의 트랜잭션 매니저는 Java Transaction Service(JTS)와의 호환성을 제공하며, Java Transaction

API(JTA)를 지원한다. 이는 클라이언트가 트랜잭션을 이용할 때 통일된 인터페이스와 기능을 제공하기

위함이다. 자세한 내용은 관련 API 문서나, 스펙 문서를 참고한다.

또한 다양한 형태의 애플리케이션을 지원하기 위하여, 애플리케이션이 동작할 수 있는 여러 가지 상황(클

라이언트, 서버 애플리케이션)에서의 트랜잭션 서비스를 제공한다.

트랜잭션 매니저는 안정적인 서비스 제공을 위하여, 문제 상황이 발생하더라도 트랜잭션의 무결성을 보

장해야 한다. 이를 위해 JEUS 트랜잭션 매니저는 트랜젹션 복구(Transaction Recovery) 기능을 제공하여,

다양한 문제 상황 이후에 트랜잭션을 복구할 수 있도록 한다.

JEUS에서의 트랜잭션 작업에 참여하는 요소는 다음과 같이 크게 3가지로 나누어진다.

● 첫 번째로, 서비스를 받는 입장에서의 애플리케이션이 있다.

애플리케이션은 웹 컨테이너나 EJB 컨테이너, 클라이언트 컨테이너를 통해서 다양한 리소스 매니저로

접속할 수 있다. 애플리케이션은 스스로 트랜잭션의 작업과 끝을 지정하여 트랜잭션을 조정할 수도 있

고, 컨테이너의 트랜잭션 매니저가 그러한 작업들을 대신 할 수도 있다.

● 두 번째로 그 애플리케이션에 트랜잭션 관리 기능과 그에 따르는 인터페이스를 제공하는 트랜잭션 매

니저가 있다.

트랜잭션 매니저는 애플리케이션의 동작 위치에 따라 서버 또는 클라이언트 트랜잭션 매니저로 나뉘며,

실제 리소스 매니저에 직접적으로 트랜잭션 작업을 준비, 반영 요청을 전달하는 일을 한다.

● 세 번째로 실제 트랜잭션들이 영향을 주게 되는 리소스 매니저(예를 들면 DB)가 위치하게 된다.

리소스 매니저는 이러한 요청들을 받아들여 실제 작업을 하게 된다.

제9장 트랜잭션 매니저 115

각 구성 요소는 트랜잭션 처리를 위하여 표준 API인 JTA를 이용하여 서로 통신한다.

본 절에서는 각 요소에 대해 설명하며, 각각에 대해 동작 방식을 알아보도록 한다. 트랜잭션의 기본적인

내용은 관련 서적이나 자료 등을 참고한다.

9.1.1. 애플리케이션

애플리케이션은 JEUS 트랜잭션 매니저를 이용하여 리소스 매니저에 트랜잭션 관련 작업을 수행한다. 애

플리케이션은 몇 개의 리소스 매니저를 이용하느냐에 따라 로컬 트랜잭션과 글로벌 트랜잭션 2가지를 사

용할 수 있다. 또한 트랜잭션의 결정 권한을 갖는 주체에 따라서 설정 및 프로그래밍 방식에 따라 나뉠 수

있다.

다음은 이러한 분류에 대한 설명이다.

● 로컬 트랜잭션

하나의 리소스 매니저를 사용하는 트랜잭션 작업들은 하나의 로컬 트랜잭션으로 묶일 수 있다. 애플리

케이션은 리소스 매니저의 드라이버를 사용해서 로컬 트랜잭션을 시작하거나 종료한다.

기본적으로 JEUS 트랜잭션 매니저는 로컬 트랜잭션 처리에는 관여하지 않는다. 애플리케이션이 작업

을 글로벌 트랜잭션으로 처리할 수 있지만, 하나의 리소스 매니저를 이용하는 단순한 트랜잭션의 작업

을 할 경우라면 로컬 트랜잭션이 훨씬 효율적이므로 로컬 트랜잭션을 사용하길 권장한다.

● 글로벌 트랜잭션

애플리케이션이 2개 이상의 리소스 매니저를 이용하여 일련의 트랜잭션 작업을 시도할 경우, 트랜잭션

매니저는 이 트랜잭션들을 하나의 글로벌 트랜잭션으로 묶어서 처리할 수 있다. 이 글로벌 트랜잭션은

흔히 2 Phase Commit 프로토콜을 사용하여, 사용 중인 리소스들에 대해 일괄적인 트랜잭션 작업을 가

능하게 해준다.

트랜잭션 매니저는 트랜잭션을 commit할 때 애플리케이션의 실행 흐름을 추적해서 1 Phase Commit을

할지 2 Phase Commit을 할지를 결정한다. 이 결정은 트랜잭션 내에 사용된 리소스 매니저의 개수와 타

입에 따라서 결정된다. JEUS 트랜잭션은 중복된 트랜잭션을 지원하지 않으며, 2개의 트랜잭션이 섞여

서 진행하는 것은 허락하지 않는다.

● User-Managed 트랜잭션

애플리케이션은 javax.transaction.UserTransaction 객체를 사용해서 트랜잭션의 시작과 종료 시기를

지정할 수 있다. 트랜잭션을 commit할 것인지 rollback할 것인지는 전적으로 애플리케이션에 의해 결정

된다. 그러나 commit을 했음에도 불구하고, 리소스 매니저가 트랜잭션을 처리할 수 없을 때 JEUS 트랜

잭션 매니저가 rollback시킬 수도 있다.

EJB에서는 이 User Managed 트랜잭션을 Bean-Managed 트랜잭션(BMT)이라고 부른다.

● Container-Managed 트랜잭션

Container Managed 트랜잭션은 컨테이너가 트랜잭션의 시작과 종료시기를 결정하는 방식이다. 트랜

잭션의 commit, rollback 등의 결정은 전적으로 컨테이너에 의해 결정된다. EJB에서만 사용할 수 있으

며 Bean의 각 메소드 별로 트랜잭션 속성 NotSupported, Required, Supports, RequiresNew, Mandatory,

Never를 지정해서 사용한다.


9.1.2. JEUS 트랜잭션 매니저

JEUS는 서버 트랜잭션 매니저와 클라이언트 트랜잭션 매니저의 2가지 트랜잭션 매니저를 제공한다.

서버 트랜잭션 매니저는 글로벌 트랜잭션을 관리하기 위한 모든 기능을 제공한다. 반면에 클라이언트 트

랜잭션 매니저는 서버 트랜잭션의 대행(proxy) 역할만을 수행한다.

서버 트랜잭션 매니저(Server Transaction Manager)

서버 트랜잭션 매니저는 Java Transaction API를 완전 구현했으며, 서버 애플리케이션이 트랜잭션을 사

용할 경우 동작한다.

글로벌 트랜잭션이 시작되면 서버 트랜잭션 매니저는 글로벌 트랜잭션과 관련된 모든 정보를 수집해서,

트랜잭션의 Coordinator로서 작업을 진행한다. 상황에 따라서 Root Coordinator와 Sub Coordinator로

역할이 나뉜다.

● Root Coordinator : 트랜잭션이 시작되는 트랜잭션 매니저가 담당하며, 여기서 시작된 트랜잭션이 전파

되는 매니저는 Sub Coordinator가 된다.

● Sub Coordinator : Root Coordinator로부터 결정을 받아 해당하는 작업을 수행한다.

즉 능동적으로 트랜잭션을 관리하는 역할이 Root Coordinator, 이 내용을 따라 하는 수동적 역할이 Sub

Coordinator가 할 일이다.

[그림 9.1] Root Coordinator와 Sub Coordinator의 관계 예제

클라이언트 트랜잭션 매니저(Client Transaction Manager)

클라이언트 트랜잭션 매니저는 서버 트랜잭션 매니저의 대행자(proxy)로 작동한다.

글로벌 트랜잭션의 신호를 받은 서버 트랜잭션 매니저가 Root Coordinator의 역할을 하게 되며, 해당 트랜

잭션에 관한 정보를 모두 모아서 처리한다. commit 시점에 클라이언트 트랜잭션 매니저는 commit 신호를

Root Coordinator에 전송하고, commit의 결과를 받게 된다.


9.1.3. 리소스 매니저

애플리케이션은 다양한 리소스 매니저와 작업을 할 수 있다. 커넥션 매니저는 리소스 매니저(이하 RM)와

의 연결을 관리한다.

JEUS에서는 4가지 타입의 커넥션 매니저를 제공한다. JDBC Connection Manager와 JMS Connection

Manager, WebT Connection Manager, 그리고 Connector Manager가 그것이다. 글로벌 트랜잭션을 위해

서 커넥션 매니저는 트랜잭션과 관련되는 정보를 트랜잭션 매니저에 보고한다.

● JDBC RM

Java Database Connectivity(JDBC)는 Java 언어로 개발할 때 사용하는, 데이터베이스와 애플케이션

간의 연결을 정의한 것이다. 애플리케이션은 JDBC RM을 Naming Server로부터 lookup해서 사용한다.

자세한 것은 “제6장 JNDI Naming Server”와 “제8장 DB Connection Pool과 JDBC”를 참고한다.

● JMS RM

Java Message Service(JMS)는 Queue와 Topic 그리고 거기에 저장된 메시지에 액세스하기 위한 API

를 정의한 스펙이다. 자세한 내용은 "JEUS MQ 안내서"나 JMS 스펙을 참고한다.

● Tmax (WebT) RM

Tmax는 TmaxSoft에서 개발된 TP-monitor이다. JEUS에서는 Tmax의 트랜잭션 매니저와 투명한 양방

향 서비스를 위해서 WebT라는 Bridge를 제공한다. WebT는 양방향 메소드 호출을 지원한다. 그래서

Tmax위에서 일반적인 EJB 클라이언트가 작동될 수 있으며, JEUS에 있는 EJB Bean을 동일한 방법으

로 호출할 수 있다.

● Java Connector Architecture (JCA) RM

JCA는 JavaEE 스펙 중의 하나로서, JavaEE 호환 플랫폼과 다양한 EIS(Enterprise Information System)

와의 통합 메커니즘을 제공한다. XA 트랜잭션을 지원하는 Connector를 사용해서, 애플리케이션이 다

양한 트랜잭션 작업을 하나의 글로벌 트랜잭션으로 다룰 수 있다. 자세한 내용은 "JEUS JCA 안내서"를

참고한다.

9.2. 서버 트랜잭션 매니저 설정JEUS 트랜잭션 매니저의 설정 방법에 대해 설명한다.

JEUS 사용자는 설정을 통해 다양한 선택을 할 수 있다. 이러한 선택 사항들은 JEUS 트랜잭션 매니저의

성능 및 동작에 큰 영향을 미치게 된다. 그러므로 각각의 내용을 숙지하고 알맞은 설정을 하도록 한다.

참고

트랜잭션 매니저의 설정은 JEUSMain.xml 파일을 직접 수정하거나, WebAdmin에서 설정할 수 있다.

기본적으로 WebAdmin을 통해 설정하기를 권장한다.

다음은 서버 트랜잭션 매니저의 설정에 대한 예로 JEUSMain.xml의 각 <engine-container>의 <tm-config>

태그에 설정한다.



<jeus-system>

<node>

. . .

<engine-container>

. . .

<tm-config

. . .

</tm-config>

. . .

</engine-container>

. . .

</node>

. . .

</jeus-system>

이 외에도 Java 시스템 프로퍼티를 이용하여 설정할 수도 있다. 서버 트랜잭션 매니저의 경우 JEUSMain.xml

의 설정 파일을 이용할 수 있지만, 클라이언트 애플리케이션은 그럴 수 없기 때문에 이런 방식을 제공한

다. 이후 내용은 JEUSMain.xml에 작성되어야 하는 내용을 중점적으로 다룬다. 서버 트랜잭션 매니저의

경우 시스템 프로퍼티를 이용한 설정을 지양하고, JEUSMain.xml을 이용한 설정이나, WebAdmin을 이용

한 설정 방법을 주로 사용하도록 한다.

9.2.1. Worker Thread Pool 설정

JEUS 트랜잭션 매니저에서는 다른 트랜잭션 매니저 간의 통신을 지원하기 위해서 여러 개의 Worker

Thread를 사용한다. Worker Thread Pool은 다음과 같은 속성으로 설정된다.

다음은 Worker Thread Pool 설정에 대한 예로 JEUSMain.xml의 <engine-container> 태그 내부의 <tm-

config><pooing>...</pooling></tm-config> 태그에서 설정한다.

[예 9.2] Worker Thread Pool 설정 : <<JEUSMain.xml>>

<jeus-system>

<node>

. . .

<engine-container>

. . .

<tm-config>

<pooling>

<min>10</min>

<max>50</max>


</pooling>

. . .

</tm-config>

. . .


</engine-container>

. . .

</node>

. . .

</jeus-system>


설명태그

Pool에 생성되는 Worker Thread의 수로 클라이언트 트랜잭션 매니저에서 이 값을 설

정하려면, <pool>의 <min> 태그에서 설정한다.

<min>

Pool에 생성되는 Thread의 최대 개수로 서버 트랜잭션 매니저에서 설정하려면 <pool>

의 <max> 태그에서 설정한다.

<max>

Worker Thread를 정리하기 위해서 Pool을 검사하는 시간 간격으로 서버 트랜잭션 매

니저에서 설정하려면 <pool>의 <period> 태그에서 설정한다.(단위 : ms)

<period>

9.2.2. 타임아웃 설정

JEUS 트랜잭션 매니저는 예외 상황 처리를 위해서 다양한 타임아웃 메커니즘을 사용한다. 타임아웃 메커

니즘의 값을 조정해서 애플리케이션 시스템에 가장 적합하도록 트랜잭션 매니저를 튜닝할 수 있다. 타임

아웃의 단위는 모두 ms이다.

다음은 타임아웃 설정에 대한 예이다.

[예 9.3] 타임아웃 설정 : <<JEUSMain.xml>>

<jeus-system>

<node>

. . .

<engine-container>

. . .

<tm-config>

<pooling>

<min>10</min>

<max>50</max>


</pooling>

<active-timeout>300000</active-timeout>

<prepare-timeout>300000</prepare-timeout>

<prepared-timeout>300000</prepared-timeout>

<commit-timeout>300000</commit-timeout>

<recovery-timeout>100000</recovery-timeout>

. . .

</tm-config>

. . .


</engine-container>

. . .

</node>

. . .

</jeus-system>


설명태그

글로벌 트랜잭션이 시작되면 이 시간 안에 Commit이 실행되어야 한다. 그렇지

않으면 트랜잭션 매니저가 Rollback 시킨다. 웹 컨테이너나 EJB 컨테이너에 설

정하려면 <active-timeout> 태그에 값을 설정한다.

<active-timeout>

Root Coordinator는 이 시간 내에 Sub Coordinator와 리소스 매니저로부터 ‘pre

pare’ 신호를 받아야 한다. 만약 받지를 못하면 Root Coordinator는 글로벌 트랜

<prepare-timeout>

잭션을 Rollback 시킨다. 웹 컨테이너나 EJB 컨테이너에 설정하려면 <prepare-

timeout> 태그에 값을 설정한다.

Sub Coordinator는 자신의 Root Coordinator로부터 이 시간 안에 Commit을 해

야 할지, Rollback을 해야 할지를 나타내는 글로벌 decision을 받아야 한다.

<prepared-timeout>

만약 이 시간 내에 받질 못하면, Root Coordinator로 다시 ‘prepare’에 대한 응답

메시지를 보낸다. 그래도 여전히 시간 내에 글로벌 decision이 오지 않는다면, 글

로벌 트랜잭션을 Rollback 시킨다. 웹 컨테이너나 EJB 컨테이너에 설정하려면

<prepared-timeout> 태그에 값을 설정한다.

Root Coordinator는 이 시간 내에 Sub Coordinator와 리소스 매니저로부터

‘commit’이나 ‘rollback’ 에 대한 결과를 받아야 한다.

<commit-timeout>

만약 결과가 오지 않으면, Root Coordinator는 글로벌 트랜잭션을 ‘Uncompleted

List’에 기록해서, 트랜잭션이 완전히 끝나지 않았음을 남겨둔다. 웹 컨테이너나

EJB 컨테이너에 설정하려면 <commit-timeout> 태그에 값을 설정한다.

트랜잭션 복구하는 경우에 사용되는 값이다.<recovery-timeout>

트랜잭션 매니저는 트랜잭션 복구를 위해서 복구될 트랜잭션 정보를 가져오려

고 한다. 만약 다른 트랜잭션 매니저에서 이 시간 내에 복구 정보를 알려주지 않

으면 해당 트랜잭션을 Rollback시킨다.

웹 컨테이너나 EJB 컨테이너에 설정하려면 <recovery-timeout> 태그에 값을 설

정한다.


9.2.3. 트랜잭션 매니저 용량 설정

이 값을 사용해서 JEUS 트랜잭션 매니저는 내부 구조를 최적화시킨다. 트랜잭션 매니저가 동시에 처리하

는 글로벌 트랜잭션의 개수를 고려해서 값을 설정한다.

웹 컨테이너나 EJB 컨테이너에서 설정하려면 JEUSMain.xml의 <tm-config><capacity>에서 값을 설정

한다.

[예 9.4] 트랜잭션 매니저 용량 설정 : <<JEUSMain.xml>>

<jeus-system>

<node>

. . .

<engine-container>

. . .

<tm-config>

. . .

<capacity>20000</capacity>

. . .

</tm-config>

. . .

</engine-container>

. . .

</node>

. . .

</jeus-system>

9.2.4. Root Coordinator와 Sub Coordinator 관련 설정

트랜잭션 매니저는 역할에 따라 Root Coordinator와 Sub Coordinator로 나누어 진다.

Sub Coordinator는 Root Coordinator로부터 트랜잭션 관련 사항을 전파받아야 하기 때문에 Root Coordi

nator에 자신을 등록시켜 Root가 자신의 존재를 알게 한다.

이와 관련 된 설정으로 다음에 나열된 2가지가 있다. 사용자는 퍼포먼스와 안정성을 고려해서 옵션을 적

절히 사용하도록 한다.

● -Djeus.tm.forcedReg=<true or false>

이 설정은 Sub Coordinator가 Root Coordinator에게 언제 자신을 등록시킬 것인가에 대한 설정이다.

설명설정값

트랜잭션 전파 상황에서 Sub Coordinator는 곧바로 자신을 등록한다.(기본값)true

실제로 Sub Coordinator에 연결된 리소스 매니저를 사용할 때 Root Coordinator에 등록

한다. 이렇게 할 경우, 실제 Sub Coordinator에 등록 된 리소스 매니저를 사용하지 않는

EJB Call이 많은 경우에, 트랜잭션 매니저 간의 통신 횟수를 줄일 수 있다.

false


● -Djeus.tm.checkReg=<true or false>

설명설정값

Sub Coordinator가 자신을 등록할 때, Root로부터 ACK를 기다린다. 만약 일정 시간 내에

ACK가 도착하지 않으면 등록 실패로 간주하고 대기 중인 트랜잭션들을 Rollback을 시킨

다.(기본값 : ture)

true

이와 더불어 트랜잭션 매니저 사이의 통신 방식을 결정해 줄 수도 있다. 여기서 말하는 통신 방식이란 Non-

blocking I/O와 Blocking I/O 2가지이다.

● <tm-config> <use-nio>...</use-nio> </tm-config> 또는 -Djeus.tm.usenio=<true or false>

– true일 경우 Non-blocking I/O를 이용하여 결정한다. 기본값은 서버일 경우 true, 클라이언트일 경우

false이다.

9.2.5. 트랜잭션 Join 설정

JEUS 트랜잭션 매니저는 같은 RM의 트랜잭션 리소스들은 서로 Join을 시킨다. 이렇게 할 경우 추가적인

트랜잭션 브랜치를 생성하지 않고도 작업을 하게 되어, 오버헤드를 줄일 수 있다. 하지만 상황에 따라서는

이러한 방식이 문제가 될 수도 있다(예를 들면 Oracle OCI를 RAC처럼 사용할 때). 이럴 때에는 다음의 옵

션을 true로 지정하여 문제 발생을 대비한다.

-Djeus.tm.disableJoin=<true or false>

9.3. 클라이언트 트랜잭션 매니저 설정클라이언트 트랜잭션 매니저는 클라이언트 애플리케이션이 글로벌 트랜잭션을 시작하고 종료하기 위해

서 만들어졌다. 본 절에서는 클라이언트에 특별한 의미를 갖는 설정들에 대해 설명한다.

클라이언트 애플리케이션은 JEUSMain.xml의 설정 등을 사용하지 않기 때문에 애플리케이션 실행 스크

립트에 시스템 프로퍼티 형태로 설정을 지정한다.

9.3.1. 트랜잭션 매니저 사용 유무 설정

클라이언트 트랜잭션 매니저는 클라이언트 애플리케이션이 JNDI lookup을 사용할 때 초기화된다. 그러나

클라이언트 애플리케이션에 따라 트랜잭션 매니저를 사용하지 않는 경우가 있다. 이럴 때 생기는 추가적

인 오버헤드를 없애기 위해 이 내용을 실행 스크립트에 저장한다.

-Djeus.tm.not_use=<true or false>


9.3.2. 트랜잭션 매니저 타입 설정

클라이언트 트랜잭션 매니저는 클라이언트 컨테이너에서만 사용된다. 사용하려면 다음을 클라이언트 애

플리케이션 스크립트에 추가한다.

-Djeus.tm.version=client

9.3.3. 트랜잭션 매니저의 TCP Port 설정

클라이언트 트랜잭션 매니저는 다른 트랜잭션 매니저와 통신하기 위해서 TCP/IP Port를 사용한다. 기본

적으로 클라이언트 트랜잭션 매니저는 적절한 Port를 스스로 찾아서 사용하나, 직접 설정하려면 다음을

클라이언트 애플리케이션 스크립트에 추가한다.

-Djeus.tm.port=<port number>

9.3.4. Worker Thread Pool 설정

● Min

– Pool에 생성되는 Worker Thread의 수로 클라이언트 트랜잭션 매니저에서 이 값을 설정하려면 다음

의 내용을 클라이언트 실행 스크립트에 넣어준다.

-Djeus.tm.tmMin=<number of threads>

● Max

– Pool에서 생성되는 Thread의 최대 개수로 클라이언트 트랜잭션 매니저에서 이 값을 설정하려면 다음

의 내용을 클라이언트 실행 스크립트에 넣어준다.

-Djeus.tm.tmMax=<number of threads>

● Resizing Period

– Worker Thread를 정리하기 위해서 Pool을 검사하는 시간 간격으로 클라이언트 트랜잭션 매니저에서

이 값을 설정하려면 다음의 내용을 클라이언트 실행 스크립트에 넣어준다.

-Djeus.tm.resizingPeriod=<number of threads>

9.3.5. 타임아웃 설정

● Active Timeoutt

– 글로벌 트랜잭션이 시작되면 이 시간 안에 commit이 실행되어야 한다. 그렇지 않으면 트랜잭션 매니

저가 Rollback 시킨다.


– 클라이언트 컨테이너에서 이 값을 설정하려면 클라이언트 애플리케이션의 스크립트에 다음을 추가

한다.

-Djeus.tm.activeto=<time in milliseconds>

● Prepare Timeout

– Root Coordinator는 이 시간 내에 Sub Coordinator와 리소스 매니저로부터 ‘prepare’ 신호를 받아야

한다. 만약 받지를 못하면 Root Coordinator는 글로벌 트랜잭션을 Rollback 시킨다.


한다.

-Djeus.tm.prepareto=<time in milliseconds>

● Prepared Timeout

– Sub Coordinator는 자신의 Root Coordinator로부터 이 시간 안에 Commit을 해야 할지, Rrollback을

해야 할지를 나타내는 글로벌 decision을 받아야 한다. 만약 이 시간 내에 받질 못하면, Root Coordinator

로 다시 ‘prepare’에 대한 응답 메시지를 보낸다. 그래도 여전히 시간 내에 글로벌 decision이 오지 않

는다면, 글로벌 트랜잭션을 Rollback 시킨다.


한다.

- Djeus.tm.preparedto=<time in milliseconds>

● Commit Timeout

– Root Coordinator는 이 시간 내에 Sub Coordinator와 리소스 매니저로부터 ‘commit’이나 ‘rollback’ 에

대한 결과를 받아야 한다. 만약 결과가 오지 않으면, Root Coordinator는 글로벌 트랜잭션을 ‘Uncom

pleted List’에 기록해서, 트랜잭션이 완전히 끝나지 않았음을 남겨둔다.


한다.

- Djeus.tm.committo =<time in milliseconds>

● Recovery Timeout

– 트랜잭션을 복구하는 경우에 사용된다. 트랜잭션 매니저는 트랜잭션 복구를 위해서 복구될 트랜잭션

정보를 가져오려고 한다. 만약 다른 트랜잭션 매니저에서 이 시간 내에 복구 정보를 알려주지 않으면

해당 트랜잭션을 Rollback 시킨다.


한다.

-Djeus.tm.recoveryto=<time in milliseconds>


9.3.6. 트랜잭션 매니저 용량 설정

이 값을 사용해서 JEUS 트랜잭션 매니저는 내부 구조를 최적화시킨다. 트랜잭션 매니저가 동시에 처리하

는 글로벌 트랜잭션의 개수를 고려해서 값을 정한다. 클라이언트 컨테이너에서 이 값을 설정하려면 클라

이언트 애플리케이션 스크립트에 다음을 추가한다.

-Djeus.tm.capacity=<number of concurrent transactions>

9.4. 트랜잭션 애플리케이션 작성본 절에서는 JEUS 트랜잭션 프로그래밍 예제를 설명한다. 로컬 트랜잭션과 클라이언트 관리(Client-

managed) 트랜잭션, Bean 관리(Bean-managed) 트랜잭션 그리고 컨테이너 관리(Container-managed)

트랜잭션에 대해서 설명한다. 사용자 및 애플리케이션 프로그래머는 현재 자신의 애플리케이션이 어떤

양식으로 운영되어야 하는가를 확실히 지정한 후 프로그래밍을 해야 한다. 그래야만 예측된 결과를 얻을

수 있으며, 추후 문제 발생시 쉬운 문제해결이 가능하다.

애플리케이션은 트랜잭션 작업을 하나의 트랜잭션으로 관리할 수 있다. 작업이 하나의 리소스 매니저를

통해서 처리된다면 로컬 트랜잭션을 형성한다. 그렇지 않다면 트랜잭션을 관리하기 위해서 글로벌 트랜

잭션을 사용할 수밖에 없다.

트랜잭션 프로그래밍 패턴에는 4가지가 있다.

● 로컬 트랜잭션(Local Transaction)

● 클라이언트 관리 트랜잭션(Client Managed Transaction)

● Bean 관리 트랜잭션(Bean-Managed Transaction)

● 컨테이너 관리 트랜잭션(Container Managed Transaction)

9.4.1. 로컬 트랜잭션

로컬 트랜잭션(Local Transaction)은 하나의 리소스 매니저에 대한 트랜잭션 작업을 관리하는 데 효과적

인 방법이다. 가볍고 빠르기 때문에 가능하면 로컬 트랜잭션을 사용한다. 로컬 트랜잭션은 JEUS 트랜잭

션 매니저와는 아무런 관계가 없으며, 모든 타입의 컨테이너에서 사용할 수 있다.

다음은 로컬 트랜잭션을 사용하는 간단한 예제이다. 비록 Java 애플리케이션이지만 코드 일부분은 서블

릿이나 EJB 등과 같은 다른 JavaEE 프로그래밍에서도 사용할 수 있다.

[예 9.5] <<Client.java>>

import javax.naming.*;

import javax.rmi.PortableRemoteObject;

import java.util.*;

import javax.transaction.UserTransaction;

import java.sql.*;

import javax.sql.*;


public class Client {

private static Connection con;

private static Connection getConnection() throws

NamingException, SQLException {

// get a JDBC connection

}

private static String insertCustomer(String id, String name,

String phone) throws NamingException, SQLException {

// insert a product entity given by the arguments to DB

}

private static void deleteCustomer(String id) throws

NamingException, SQLException {

// delete a product entity given by the arguments from DB

}

public static void main(String[] args) {

try {

// get a JDBC connection

con = getConnection();

// set the autocommit attribute as false

con.setAutoCommit(false);

// insert customers

for (int i=0 ; i<number/2 ; i++) {

System.out.println("inserting customer id="+i+"c... from Client");

customers[i] =

insertCustomer(i+"c", "Hong Kil Dong "+i, "000-123-1234-"+i);

}

System.out.println("completed inserting customers!!");

con.commit();

// delete customers


System.out.println(

"deleting customerid="+customers[i]+" ... from Client");

deleteCustomer(customers[i]);

}

System.out.println("completed deleting customers!!");

con.commit();

} catch (NamingException ne) {

System.out.println("Naming Exception caught : " + ne.getMessage());


} catch (SQLException sqle) {

System.out.println("SQL Exception caught : " + sqle.getMessage());


try {

con.rollback();

} catch (Exception ee) {

System.out.println("Transaction Rollback error : " + ee.getMessage());

}

System.out.println("Error caught : " + e.getMessage());

e.printStackTrace();

} finally {

try {

if (con!=null) con.close();

} catch (SQLException se) {}

}

}

}

9.4.2. 클라이언트 관리 트랜잭션

클라이언트 컨테이너(Client Managed Transaction)의 애플리케이션에서 글로벌 트랜잭션을 사용할 수 있

다. 클라이언트는 UserTransaction을 이용하여 직접 트랜잭션을 관리하고, 실제 작업을 해주는 EJB를 호

출한다. 다음은 간단한 예제이다.

클라이언트

글로벌 트랜잭션을 시작하기 전에, ‘java:comp/UserTransaction’을 lookup해서 javax.transaction.UserTrans

action의 인스턴스를 가져온다. 이 인스턴스의 begin()을 호출해서 글로벌 트랜잭션을 시작한 다음에, EJB

Bean을 여러 번 호출한다. EJB Bean의 트랜잭션 작업을 Commit하려면 UserTransaction 인스턴스의

commit() 메소드를 실행해서 트랜잭션이 완료되었음을 알린다.

정상적으로 Commit이 되었다면 메소드는 끝나게 된다. 장애가 발생해서 글로벌 트랜잭션이 Commit되지

못한다면 메소드에서 Exception을 던지게 된다. javax.transaction.RollbackException은 JEUS 트랜잭션

매니저가 글로벌 트랜잭션이 Rollback 되었다는 것을 보장하는 Exception이다. 이외에 다른 Exception은

JEUS 트랜잭션 매니저가 예측할 수 없는 Exception이 발생해서 글로벌 트랜잭션을 Rollback하려고 한다

는 것을 나타낸다. 그러나 글로벌 트랜잭션에 포함된 모든 트랜잭션 작업들이 완전히 Rollback된다는 것

은 아니다. 이럴 때는 catch문 안에서 다시 한 번 직접 UserTransaction 의 rollback() 메소드를 호출해 글

로벌 트랜잭션을 Rollback 시켜준다.


package umt;

import javax.naming.InitialContext;

import javax.naming.NamingException;



import java.util.*;




UserTransaction tx = null;

try {

InitialContext initial = new InitialContext();

ProductManager productManager =

(ProductManager)initial.lookup("productmanager");

System.out.println("");

System.out.println("< Testing ProductManager EJBBean " +

"Using User Managed Transaction >>");

System.out.println("");

int number = 10;

String products[] = new String[number];

tx = (UserTransaction)initial.lookup("java:comp/UserTransaction");

tx.begin();

// insert products


System.out.println("inserting product id="+i+"b

...");

products[i] = productManager.insertProduct(

i+"b","ball pen", i*10); // bean call

}

for (int i=number/2 ; i<number ; i++) {

System.out.println("inserting product id="+i+"f...");

products[i] = productManager.insertProduct(

i+"f", "fountain pen", (i-number/3)*50);

}

System.out.println("completed inserting products!!");

// delete products

for (int i=0 ; i<number ; i++) {

System.out.println("deleting productid="+products[i]+" ...");

productManager.deleteProduct(products[i]); // bean call

}

System.out.println("completed deleting products!!");

tx.commit();

} catch (javax.transaction.SystemException se) {

System.out.println("Transaction System Error caught : " + se.getMessage());

} catch (javax.transaction.RollbackException re) {

System.out.println(

"Transaction Rollback Errorcaught : " + re.getMessage());


try {

tx.rollback();



System.out.println("Transaction Rollback error : " + ee.getMessage());

}

System.out.println("Error caught : " + e.getMessage());


}

}

}

}

EJB

다음의 EJB Bean은 트랜잭션 작업을 하는 메소드를 가지고 있다. 클라이언트에서 글로벌 트랜잭션을 관

리하기 위해서는 EJB의 트랜잭션 타입이 CMT(container-managed)여야 한다. 기본값은 CMT이므로 아무

것도 지정하지 않아도 되지만, 명시적으로 지정하고 싶다면 다음과 같이 TransactionManagerType 값을

지정해준다.

[예 9.7] <<ProductManagerEJB.java>>

package umt;

import javax.ejb.*;

import javax.annotation.*;

@Stateless

@TransactionManagement(TransactionManagementType.CONTAINER)

public class ProductManagerEJB implements ProductManager {

....

public String insertProduct(String id, String name, double

price) {


}

public void deleteProduct(String id) {

// delete a product entity indicated by the argument from

// DB

}

.....

}

9.4.3. Bean 관리 트랜잭션

Bean 관리 트랜잭션(Bean-Managed Transaction)은 웹 컨테이너와 EJB 컨테이너에서 애플리케이션은

JTA를 사용해서 글로벌 트랜잭션 경계를 정할 수 있다. 애플리케이션이 글로벌 트랜잭션을 세밀하게 조


절할 필요가 있을 때 유용한다. 실행 순서에 따라 클라이언트의 요청을 처리할 수 있기 때문에, 애플리케

이션은 자신의 판단에 따라서 Commit과 Rollback을 할 수 있다.

다음은 EJB 컨테이너에서 애플리케이션이 글로벌 트랜잭션을 실행하는 예제이다.

클라이언트

BMT(Bean Managed Transaction)에서는 EJB Bean이 글로벌 트랜잭션 영역을 처리한다. 그러므로 모든

클라이언트는 단지 트랜잭션 작업을 하는 메소드를 호출하기만 하면 된다.


package bmt;



import java.util.*;



try {

ProductManager productManager;

.......

// Getting a reference to an instance of

// ProductManager EJB bean.

.......

productManager.transactionTest();



}

}

}

EJB

EJB Bean은 글로벌 트랜잭션을 시작하기 위해서 javax.transaction.UserTransaction를 사용한다.

javax.ejb.EJBContext(본 예제에서는 EJB가 Session Bean이므로 javax.ejb.SessionContext)를 사용해서

UserTransaction의 인스턴스를 얻어온다. 글로벌 트랜잭션은 메소드의 실행으로 begin되고 Commit된다.

EJB가 BMT로 작동하려면 Annotation으로 TransactionManagement 값을 TransactionManagement

Type.BEAN으로 지정한다.


package bmt;

import javax.ejb.*;



import java.sql.*;

import java.util.*;



@Stateless

@TransactionManagement(TransactionManagementType.BEAN)


@Resource SessionContext ejbContext;

public void transactionTest() {

UserTransaction tx = null;

try {

int number = 20;


tx = ejbContext.getUserTransaction();

tx.begin();

// insert products


System.out.println("inserting product id="+i+"b ...");

products[i] = insertProduct(i+"b", "ball pen", i*10);

}



products[i] = insertProduct(

i+"f", "fountain pen", (i-number/3)*50);

}


// delete products


System.out.println("deleting product id="+products[i]+" ...");

deleteProduct(products[i]);

}


tx.commit();

} catch (javax.transaction.SystemException se) {

throw new EJBException(

"Transaction System Error caught : " + se.getMessage());

} catch (javax.transaction.RollbackException re) {


"Transaction Rollback Error caught : " + re.getMessage());


try {

tx.rollback();



"Transaction Rollback error : " + ee.getMessage());


}

throw new EJBException("Error caught : " + e.getMessage());

}

}

private String insertProduct(String id, String name, double price)

throws NamingException, SQLException {


}

private void deleteProduct(String id) throws NamingException,

SQLException {


// DB

}

// some EJB callback methods

}

9.4.4. 컨테이너 관리 트랜잭션

JavaEE 스펙에 의하면 애플리케이션은 글로벌 트랜잭션 경계(demarcation) 지정을 컨테이너에 위임할

수 있다. 웹 컨테이너나 EJB 컨테이너는 메소드와 관련된 글로벌 트랜잭션을 관리한다. 애플리케이션은

설정 파일에 메소드 별로 트랜잭션 속성을 정할 수 있다. 이 방법이 글로벌 트랜잭션을 처리하는 가장 쉬

운 방법이다.

다음은 EJB 컨테이너가 관리하는 글로벌 트랜잭션의 예를 보여준다.

클라이언트

CMT(Container Managed Transaction)에서 서버 측 EJB 컨테이너가 EJB의 글로벌 트랜잭션 작업을 관

리하는 것을 보여준다.


package bmt;



import java.util.*;



try {

ProductManager productManager;

// getting a reference to an instance of


// ProductManager EJB bean.

productManager.transactionTest();



}

}

}

EJBCMT의 장점은 EJB Bean 개발자가 비즈니스 로직 코드에서 더 이상 트랜잭션 관련 코드를 작성하지 않도

록 한다는 것이다.

EJB Bean의 메소드에 적절한 트랜잭션 속성만 지정하면 글로벌 트랜잭션관련 작업은 모두 EJB 컨테이

너에 위임된다. 다음의 예제에서 transactionTest()는 트랜잭션 관련 코드가 아무 것도 없다. EJB Bean이

CMT로 작동하도록 EJB 컨테이너에 알려주려면, TransactionManagement Annotation을 생략하거나

TransactionManagerType.CONTAINER 값으로 지정해준다.


package cmt;

import javax.ejb.*;


import java.sql.*;

import java.util.*;


@Stateless

@TransactionManagement(TransactionManagementType.CONTAINER)


public void transactionTest() {

try {

int number = 20;


// insert products


System.out.println("inserting product id="+i+"b...");

products[i] = insertProduct(i+"b", "ball pen", i*10);

}



products[i] = insertProduct(i+"f", "fountain pen", (i-number/3)*50);

}


// delete products



System.out.println("deleting product id="+products[i]+" ...");

deleteProduct(products[i]);

}



throw new EJBException("Error caught : " + e.getMessage());

}

}

private String insertProduct(String id, String name, double price)

throws NamingException, SQLException {


}

private void deleteProduct(String id) throws NamingException,

SQLException {


// DB

}

// some EJB callback methods

}

9.4.5. 트랜잭션 매니저 사용하기

트랜잭션 매니저를 직접 사용하는 경우 JNDI Context에서 java:appserver/TransactionManager의 이름으

로 lookup하면 트랜잭션 매니저를 얻을 수 있다. 트랜잭션 매니저는 트랜잭션을 시작, 종료할 수 있고 트

랜잭션 객체를 얻거나 XAResource 객체를 등록하는 기능을 제공한다. 이에 대한 자세한 설명은 Java

Transaction API (JTA) specification을 참고한다.

참고

JEUS에서 트랜잭션 매니저를 얻거나 UserTransaction을 얻는 방법은 Glassfish 혹은 SunOne Appli

cation Server와 호환된다. 따라서 Hibernate와 같은 3rd-party library를 사용할 때 호환되는 서버의

설정을 그대로 사용할 수 있다.

9.5. 트랜잭션의 복구본 절에서는 트랜잭션 복구 작업에 대해 설명한다. 트랜잭션의 복구는 예상치 못한 문제 상황에 있어 트랜

잭션 무결성을 지원하기 위한 중요한 기능이다. JEUS 사용자는 앞서 설명한 관련 설정 및 트랜잭션 복구

과정에 대해 숙지한다.


9.5.1. 트랜잭션 복구 과정

트랜잭션 매니저는 트랜잭션을 사용할 때 생길 수 있는 장애에 대한 대책을 가지고 있어야 한다. 장애 대

책은 주로 진행중이던 트랜잭션의 무결성을 보장하는데 중점을 둔다. 트랜잭션 매니저는 트랜잭션 매니

저의 역할에 따라서 복구 방식에 차이를 보인다. 즉 매니저가 Root 또는 Sub Coordinator인지, JEUS가 아

닌 다른 외부 TM과 작업중인지에 따라서 복구 방식이 달라진다.

다음의 그림은 트랜잭션 매니저의 복구 과정을 간단히 보여준다.

[그림 9.2] 단순화한 트랜잭션 복구 과정

● 1, 2) 트랜잭션 매니저가 장애 상황에서 복구 될 경우, 매니저는 트랜잭션 로그로부터 복구할 트랜잭션

정보를 얻어오게 된다.

● 3) 그 이후 로그의 내용에 따라 해당 리소스 매니저로 Recover 명령을 보낸다.

● 4) 리소스 매니저는 이에 대한 응답으로 현재 자신이 처리하지 못한 트랜잭션들의 XID를 매니저로 넘겨

준다.

● 5) 트랜잭션 매니저는 이 XID들과 로그로부터 얻어진 정보를 가지고 Commit 또는 Rollback 판정을 리

소스 매니저로 전달한다.

트랜잭션 매니저의 역할에 따라 조금씩 복구 방식의 차이는 있지만 큰 흐름은 앞서 설명한 내용을 벗어나

지 않는다. 이후 부터는 복구에 참여하는 각각의 요소에 대한 간략한 설명과 관련 설정들에 대해 설명한

다.

트랜잭션 매니저별 복구 과정

트랜잭션 복구에서 트랜잭션 매니저는 가장 중심적인 역할을 한다. 다음은 트랜잭션 매니저 역할에 따른

복구 방식의 차이에 대한 설명이다.

● Root Coordinator

트랜잭션 매니저가 Root Coordinator일 때는 [그림 9.2]와 같은 동작을 한다.

● Sub Coordinator

Sub Coordinator는 Root Coordinator에게 하나의 리소스 매니저처럼 등록이 된다.


그리고 모든 Decision을 Root로부터 받아오므로, Sub Coordinator 자신에게 등록 된 리소스 매니저와

로그 파일에 대해 Xid를 얻어오는 작업까지만 수행한다. 그 이후 Xid를 Root Coordinator로 보내고, 판

정을 기다린다. Root Coordinator로부터 판정이 넘어오면, 그 내용을 리소스 매니저에게 전달해 복구 작

업을 마무리한다.

● 외부 트랜잭션 매니저와의 작업

JEUS 트랜잭션 매니저는 Root Coordinator로서 동작을 하고, 외부 트랜잭션 매니저는 JEUS를 하나의

리소스 매니저로 인식을 한다. 그러므로 판정을 내리는 작업을 제외한 모든 작업들을 수행한다. 그 이후

외부 트랜잭션 매니저가 JEUS에게 Recover 명령 및 판정을 내리면, 그에 따라 복구 작업을 완료한다.

만약 복구 작업 도중, 어떤 문제에 의해 복구가 실패할 경우 트랜잭션 매니저는 그 리소스에 대해 추가적

인 복구를 시도한다. 이는 2분에 한 번씩 시행되며, 사용자는 시도 횟수를 지정해줄 수 있다. 시도 횟수 지

정을 위해 다음 프로퍼티를 스크립트에 추가한다. 기본값은 10이다.

-Djeus.tm.recoveryTrial=<number of trial>

9.5.2. 복구 관련 로그 파일 및 설정

트랜잭션 복구에 사용되는 로그 파일은 다음의 2가지가 있다.

● 트랜잭션의 진행 상황을 기록한 로그

● 사용했던 XA 리소스 관련 로그

로그 파일은 JEUS_HOME\logs\TM의 하위 디렉터리에 컨테이너별로 생성된다. 만약 복구가 필요없는 트

랜잭션때문에 기동 중 복구 관련 문제가 발생한다면, 이 로그를 삭제한 후 JEUS를 다시 실행한다.

하지만 시스템 관리자가 직접 복구할 경우나, 아니면 성능 향상이 필요한 경우, Logging을 막을 수도 있다.

이 기능을 설정하려면 다음을 실행 스크립트에 추가한다.

-Djeus.tm.noLogging=true

웹 컨테이너나 EJB 컨테이너에서 설정하려면 JEUSMain.xml의 <command-option> 태그에서 위와 동일

하게 설정해준다.

이 외에 현재 복구 상황을 따로 로그 파일로 분리해 볼 수도 있다. 이는 복구 상황에 대한 로그를 면밀히

살핌으로써, 트랜잭션 관련 문제를 쉽게 파악하고 해결하기 위함이다. 사용자 또는 애플리케이션 프로그

래머는 이 로그를 통해 트랜잭션 ID등을 파악하여 문제해결에 이용할 수 있다. JEUSMain.xml에 다음과

같이 설정한다.


<tm-config>

<recovery-log-file>

<name>recoveryHandler1</name>

<file-name>blah.log</file-name>

<valid-day>3</valid-day>


</recovery-log-file>

</tm-config>

이 로그는 JEUS_HOME\logs\<node-name>\<container-name> 아래 생성된다. 설정 내용은 로그 파일 핸

들러 설정과 동일하므로 이를 참고한다. 글로벌 트랜잭션 로그는 바이너리 포맷으로 복구되는 경우 사용

되며, 복구 상황 로그는 일반적인 JEUS 로그 파일이다.

9.5.3. 리소스 매니저 장애

리소스 매니저에서 장애가 발생했다면, 시스템 매니저는 jeusadmin 콘솔 툴을 사용해서 수동으로 복구

하도록 한다. 그 이유는, JEUS 트랜잭션 매니저는 리소스 매니저가 다시 트랜잭션 처리가 가능한 상태인

가를 알아낼 수 없기 때문이다. 리소스 매니저의 문제를 해결한 후에 jeusadmin 툴의 tmresync 명령어로

복구를 진행한다. jeusadmin의 자세한 사용법은 “JEUS Reference Book”의 “4.2. jeusadmin”을 참조한다.


제10장 세션 서버

본 장에서는 세션 서버에 대한 개념과 설정 방법에 대해 설명한다.

10.1. 개요세션 서버는 클라이언트의 세션 데이터를 관리하거나 백업하는 데 사용된다. 그 중에서도 특히 여러 웹 서

버들과 서블릿 엔진들이 서로 클러스터링된 환경에서 세션 데이터를 관리하고자 할 때 유용하다. JEUS에

서는 세션 데이터의 관리 방식에 따라 크게 2가지의 세션 서버를 제공한다.

하나는 모든 세션 데이터를 한곳에 집중하여 관리하는 중앙 세션 서버이고, 다른 하나는 세션 데이터들을

여러 컨테이너로 골고루 분산하여 관리하는 분산 세션 서버이다. 중앙 세션 서버의 경우 세션 서버 자체가

JEUS Manager에서 관리되며, 분산 세션 서버의 경우는 엔진 컨테이너에서 각각 관리된다.

본 장에서는 이 두 세션 서버에 대해 자세히 설명한다. 세션 서버들의 모든 사용법을 알기 위해서는 “JEUS

Web Container 안내서”의 “제2장 웹 컨테이너”도 함께 참고한다.

10.2. 중앙 세션 서버본 절에서는 JEUS 서버의 관점에서의 중앙 세션 서버에 대한 설명한다. 중앙 세션 서버는 JEUS Manager

에서 운영된다.

10.2.1. 중앙 세션 서버의 개념

간단히 세션 서버는 JEUS에서 세션 객체를 저장하는 곳이다.

세션 객체는 서블릿 API의 HTTP 세션 객체를 나타낸다. HTTP 세션같은 객체는, 상태 유지가 안 되는 프

로토콜인 HTTP 요청을 임시 데이터와 매핑한다. 그래서 이 임시 데이터를 통해서 클라이언트를 구별한

다. 이렇게 함으로써 WAS는 작업 중인 클라이언트를 다른 클라이언트와 구분할 수 있으며, 이전에 작업

한 내용을 기억할 수 있다. 이런 “Session Tracking”은 웹 사이트에서 가장 중요한 부분이다.

그러나 문제는 HTTP 세션 객체는, 그 세션이 처음 생성된 서블릿 엔진에만 저장된다는 것이다. 이는 여러

서블릿 엔진들로 클러스터링 환경을 구성했을 경우, 세션을 처음 생성한 서블릿 엔진에게 해당 클라이언

트의 모든 요청을 보내야 한다는 의미이다. 그렇지만 항상 특정 서블릿 엔진으로 요청이 간다고는 볼 수

없다. 예를 들어서 웹 서버가 세션 라우팅을 지원하지 않거나, 서블릿 엔진이 내부 에러로 인해 갑자기 종

료(Down)될 경우 세션 객체를 잃어버리게 되기 때문이다.

중앙 세션 서버는 세션 데이터들을 한 곳에 모아서 관리한다. 즉, 어떤 클라이언트를 위한 세션 객체나 특

정 서블릿 엔진에서 생성된 것도 모두 중앙 세션 서버를 이용하는 것이다. 이는 2가지의 이점이 있다.

● 첫째는, 중앙 세션 서버를 사용함으로써 더 이상 웹 서버의 세션 라우팅이 필요없다.

제10장 세션 서버 139

● 둘째는, 중앙 세션 서버를 사용하고, 백업용 중앙 세션 서버를 하나 더 사용하여 세션 데이터를 백업함

으로써 시스템이 더욱 안정화된다.

이로써 서블릿 엔진이 다운이 되더라도 안전하게 세션을 유지할 수 있다.

참고

서블릿 엔진과 관련된 세션 서버의 더 자세한 사용 방법이나 Session Tracking에 관한 내용은 “JEUS

Web Container 안내서”의 “제5장 Session Tracking”을 참고한다.

중앙 세션 서버의 구조

중앙 세션 서버는 JEUS 웹 컨테이너와 연결하여 운영되며, 웹 컨테이너에 있는 클라이언트의 세션을 라

우팅하거나 백업하는 기능을 제공한다.

중앙 세션 서버는 Session Server, Session Manager, Backup Manager, Backup Session Server, Session

Cache Memory, Session Storage 등 6가지 파트로 되어있다.

다음 그림은 하나의 중앙 세션 서버에 대한 구조이다. 여러 개의 서브 컴포넌트로 구성된 것을 확인할 수

있다.

[그림 10.1] 세션 서버의 구조

Session Server

Session ManagerBackup Manager

(check TO)Cached session

Session Storage(FileDBPath: JEUS_HOME\sessiondb\central\

<file_db_path>\<file_db_name>1.fdb)

Backup Session Server

passivation timeout -> passivate

removal timeout -> remove

getSessionupdateSession

중앙 세션 서버의 서브 컴포넌트는 다음과 같다.

● Session Manager

각 Session Server에는 하나의 Session Manager가 존재한다. 이는 세션 데이터를 저장하거나 요청에

의해 그 값을 가져오는 역할을 한다. 웹 컨테이너는 이 Session Manager에 연결을 맺는다.


● Cached session(Session Cache Memory)

활성화되어 있거나 한 번 사용된 세션 객체는 빠른 사용을 위해서 이곳에 저장된다.

● Backup Manager

세션 데이터를 다른 백업용 중앙 세션 서버에 백업할 때 사용된다. 백업 체크는 환경 파일에 설정된

“check-to”의 시간 단위로 이루어진다(“to”는 타임아웃(Timeout)을 의미한다).

● Backup Session Server

일반적인 중앙 세션 서버와 같으나 세션 데이터의 백업용으로 설정한 중앙 세션 서버이다.

● Session Storage

세션의 사용 빈도가 적은 세션을 위주로 세션 데이터를 다른 저장소에 저장할 때 사용된다.

Storage 공간으로는 하드 드라이브를 사용한다. Session Storage의 세션 객체는 활성화 되지 않은 것으

로 간주된다. Storage 기능을 사용할 경우 관리자가 지정한 이름을 사용하나, 지정하지 않았을 경우에

는 기본적으로 <node-name>1.fdb라는 이름으로 파일을 가진다. 세션 데이터는 “passivationTO”가 경

과되면 Session Cache Memory로부터 비활성화되어 Session Storage에 저장되고 “removalTO”가 경과

되면 영원히 삭제된다.

클라이언트와 중앙 세션 서버의 관계

웹 컨테이너는 중앙 세션 서버와 연결된다(“JEUS Web Container 안내서”의 “제2장 웹 컨테이너” 참조).

한 번 연결할 때, 웹 컨테이너는 세션 객체가 새로 생성되거나 수정된 세션으로 판단되면 중앙 세션 서버

에 세션 객체를 저장하거나 업데이트한다. 그리고 클라이언트의 요청이 들어올 때마다 저장소로부터 세

션 객체를 가지고 온다.

참고

세션의 setAttribute, removeAttribute, setMaxInactivateInterval operation이 발생했을 때 "수정된 세

션"으로 판단한다(<check-level>의 값 "set"). 단, 이런 operation이 없을지라도 세션 attribute의 object

변경을 "수정된 세션"으로 감지하고 싶을 경우, 세션 서버 설정 중 <check-level>의 값을 "modified"로

하면 된다. 또한 모든 세션을 항상 서버로 업데이트하려면 <check-level>의 값을 "all"로 설정한다. 자

세한 사항은 “10.2.2. 중앙 세션 서버의 설정”을 참고한다.

중앙 세션 서버의 세션 클러스터링

중앙 세션 서버를 가지고 있는 JEUS Manager, 또한 중앙 세션 서버를 사용할 JEUS 간에 JEUS Manager

클러스터링을 설정하면 중앙 세션 서버 간에도 자동으로 클러스터링이 형성된다. 이렇게 클러스터링된

여러 서버들 안에서는 세션 데이터를 함께 사용할 수 있다.

중앙 세션 서버는 크게 primary 타입과 backup 타입이 존재하며 클러스터링 환경에서 오직 하나씩만 존

재 가능하다. primary 타입과 backup 타입은 클러스터링 환경에서 서로 간에 세션 객체들을 백업, recovery

하며 장애가 발생하는 경우 각 세션 서버 타입의 역할에 따라 웹 컨테이너의 서비스가 원활히 유지되도록

동작한다.


세션 클러스터링을 원하는 경우 JEUS 매니저의 클러스터링을 해야 한다는 것은 반드시 명심해야 한다.

JEUS 매니저 클러스터링에 대해서는 “제4장 JEUS 클러스터링”을 참고한다.

Session Manager의 메모리 관리

여러 웹 컨테이너들이 하나의 중앙 세션 서버와 연결되고 세션의 크기 또한 큰 경우, 많은 세션들이 한곳

의 중앙 세션 서버로 집중되기 때문에 메모리의 부담이 커질수 있다. 이를 방지하기 위해 passivation 정책

을 다음과 같이 사용한다.

● passivationTO의 주기

– 메모리에 Cache된 세션을 Storage로 옮긴다.

● removalTO의 주기

– 메모리에 Cache된 세션을 삭제한다.

● -Djeus.sessionserver.memory.max 옵션

– 메모리에 저장될 세션의 최대 크기를 지정한다.

– 예를들어, 대략 100MB만을 저장하고 싶을 경우 JEUS 실행 스크립트에 다음과 같이 추가한다.

-Djeus.sessionserver.memory.max=100m

– 기본값은 -1이며 이 경우 제한이 없다(단위는 MB는 "m", KB는 "k"를 사용하며 suffix가 없을 경우 byte

단위로 취급한다).

● -Djeus.sessionserver.memory.passivationratio 옵션

– 위에서 지정한 max 크기에 도달했을 경우 상위 몇 퍼센트를 passivation할지를 결정한다.

– 예를들어, 상위 20%의 세션들을 passivation할 경우 JEUS 실행 스크립트에 다음과 같이 추가한다.

-Djeus.sessionserver.memory.passivationratio=0.2

– 기본값은 0.2이며 값은 0보다 크고 1보다 작아야 하며 "-Djeus.sessionserver.memory.max"의 값이

설정되어 있을 경우(-1이 아닌경우)만 의미있다.

● -Djeus.sessionserver.memory.enablegc 옵션

– 위에서 지정한 max 크기에 도달했을 경우 강제로 gc를 시킬지를 결정한다.

– 기본값은 false이다. "-Djeus.sessionserver.memory.max"의 값이 설정되어 있을 경우(-1이 아닌경우)

에만 의미있다.

10.2.2. 중앙 세션 서버의 설정

본 절에서는 중앙 세션 서버의 설정에 대해서 설명한다. 기본적으로 노드 클러스터링을 했을 경우에 대한

세션 서버의 설정과 노드 클러스터링을 하지 않았을 경우의 설정에 대해서 설명한다.


참고

JEUS 웹 컨테이너에서 중앙 세션 서버를 사용하기 위한 설정 방법은 “JEUS Web Container 안내서”

의 “제2장 웹 컨테이너”를 참고한다.

중앙 세션 서버 기본 설정

중앙 세션 서버는 JEUSMain.xml 파일의 <node>절 안에 하나만 존재해야 한다.

다음은 노드 johan과 johan1이 노드 클러스터링을 통한 Session Clustering을 구성한 예제이다.

[예 10.1] 중앙 세션 서버 기본 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan</name>

. . .

<session-server>

<type>primary</type>

<thread-pool>

<min>10</min>

<max>20</max>

</thread-pool>

<resolution>30000</resolution>

<connect-timeout>60000</connect-timeout>

<read-timeout>60000</read-timeout>

<passivation-to>1800000</passivation-to>

<removal-to>3600000</removal-to>

<check-to>20000</check-to>

<backup-trigger>500</backup-trigger>

<check-level>set</check-level>

<file-db-path>c:\sessiondata</file-db-path>

<file-db-name>sessiondata</file-db-name>

<min-hole>2000</min-hole>

<packing-rate>0.8</packing-rate>

<recovery-mode>active</recovery-mode>

</session-server>

. . .

</node>

<node>

<name>johan1</name>

. . .

<session-server>

<type>backup</type>

<thread-pool>

<min>10</min>


<max>20</max>

</thread-pool>













</session-server>

. . .

</node>

. . .

</jeus-system>


설명태그

중앙 세션 서버의 타입을 설정한다.<type>

"primary" 또는 "backup"을 지정할 수 있으며, 이 타입은 클라이언트 side 즉, 웹 컨

테이너의 입장에서 볼 때 이 중앙 세션 서버가 어떤 역할을 할지를 선택한다. 세션

클러스터링 환경에서는 오직 하나의 primary 타입, 오직 하나의 backup 타입의 총

2가지만 존재해야 한다. 이 설정을 하지 않았을 경우는 primary 타입으로 간주한

다.

중앙 세션 서버에서 사용되는 소켓 커넥션 처리를 위한 Thread Pool을 설정한다.<thread-pool>

세션 데이터의 passivation/removal을 체크하는 주기를 결정한다.<resolution>

소켓 커넥션을 생성할 때 적용되는 타임아웃 값이다.<connect-timeout>

매니저에 존재하는 중앙 세션 서버 간(primary, backup 간)의 타임아웃과 중앙 세

션 서버의 타입이 primary일 경우, 중앙 세션 서버와 연결되는 웹 컨테이너와 중앙

세션 서버 간의 타임아웃, 이렇게 크게 2가지 의미로 사용된다.

통신시에 적용되는 reply에 대한 타임아웃 값으로 데이터를 보낸 후 응답을 기다

리는 최대시간이다.

<read-timeout>

이 또한 매니저에 존재하는 중앙 세션 서버간의 타임아웃과 중앙 세션 서버의 타

입이 primary일 경우 중앙 세션 서버와 연결되는 웹 컨테이너와 중앙 세션 서버간

의 타임아웃, 이렇게 크게 2가지 의미로 사용된다.

세션 객체가 Session Storage로 옮겨지기 전에 얼마나 오랫동안 Cache Memory

에 남아있을 것인지를 결정한다.

<passivation-to>


설명태그

세션 객체가 영구히 삭제되기 전에 얼마나 오랫동안 Session Storage에 보관될 것

인지를 결정한다.

<removal-to>

세션 데이터의 백업이 필요할 경우 백업 주기를 결정한다. 추가적으로 백업 서버

에 장애가 발생했을 경우 alive check를 위한 주기 역할도 한다.

<check-to>

중앙 세션 서버에서 현재 백업이 이루어지지 않은 세션 객체의 수가 이 값보다 크

면 백업하게 된다.

<backup-trigger>

웹 컨테이너의 세션 객체의 수정이 어느 정도 발생하였을 때 중앙 세션 서버로 세

션을 업데이트할지를 결정한다. primary 타입의 중앙 세션 서버에서만 이 설정값

이 유효하며 backup 타입의 중앙 세션 서버의 경우 설정할 필요 없다.

<check-level>

다음 중에 하나를 선택한다.(기본값: set)

- all : 세션 객체의 수정과 관계없이 항상 중앙 세션 서버로 업데이트한다.

- modified : 세션 객체의 수정사항을 검사하여 변경하는 경우 중앙 세션 서버로 업

데이트한다.

- set : 해당 세션의 setAttribute/putValue/removeAttribute/removeValue 함수 호출

이 일어난 경우에만 중앙 세션 서버로 업데이트한다.

세션 데이터를 디스크에 저장할 경로와 이름을 결정한다.<file-db-path>, <file-

db-name> 설정하지 않으면 기본적으로 JEUS_HOME \logs\sessiondb\central\<node-name>\”

경로에 <node-name>1.fdb 라는 파일로 사용된다. <node-name>은 JEUSMain.xml

의 <node><name>의 값이다.

일정 시간 file-db를 운용하면 파일의 크기가 필요이상 커지게 되는데, 현재 세션

객체 갯수 대비 파일 I/O 횟수가 이 값으로 지정된 ratio를 넘어서면 파일 packing

을 수행하여 필요이상 파일 크기가 늘어나는 것을 막는다.

<packing-rate>

이 값으로 설정한 숫자와 같거나 그 이상의 파일 I/O(예를 들면 passivation)가 발

생하면면 fdb파일을 다시 정리한다(packing).

<min-hole>

중앙 세션 서버가 내려갔다가 다시 살아났을때 다른 살아있는 중앙 세션 서버로부

터 세션들을 복구하는 모드를 결정한다.

<recovery-mode>

다음 중에 하나를 선택한다.(기본값 : active)

- active : 다른 살아있는 중앙 세션 서버로부터 메모리에 있는 세션들만 복구한다.

- all : 다른 살아있는 중앙 세션 서버로부터 파일 저장소 및 메모리에 있는 세션들

모두를 복구한다.

- none : 세션을 복구하지 않는다.


중앙 세션 서버에서 노드 클러스터링과 세션 클러스터링 설정

노드 클러스터링을 했을 경우 중앙식 세션 서버의 설정에 대해서 설명했다. 세션 클러스터링을 할 때 노드

클러스터링을 권장하고 있지만, 노드 클러스터링을 하지 않았을 경우에도 중앙식 세션 서버를 사용할 수

있다. 노드 클러스터링을 하지 않았을 경우에 중앙식 세션 서버의 설정은 다음과 같다.

[예 10.1]과 거의 비슷하지만, 차이점은 <node>가 JEUSMain.xml에 하나만 존재한다는 것과 <replicated-

server>를 설정하는 것이다. 그리고 <replicated-server>의 노드 이름은 vhost.properties에 설정되어 있어

야 한다.

[예 10.2] 노드 클러스터링과 세션 클러스터링 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan</name>

. . .

<session-server>

<thread-pool>

<min>10</min>

<max>20</max>

</thread-pool>














<replicated-server>johan1</replicated-server>

</session-server>

. . .

</node>

. . .

</jeus-system>



설명태그

노드 클러스터링 상태가 아닐 때 현재 세션의 replication 세션 서버의 JEUS 노

드 이름을 설정한다. replication 서버라고 하면 현재 세션 서버의 백업 서버를 의

미한다. 설정된 JEUS 노드 이름은 vhost.properties에 등록되어 있어야 한다.

<relication-server>

<replicated-server>에 설정되는 JEUS 노드 이름은 다음과 같이 vhost.properties에 설정되어야 한다.

[예 10.3] <<vhost.properties>>

jeus.vhost.enabled=true

johan1=yyy.yyy.yyy.yyy:10004

웹 컨테이너의 설정

중앙 세션 서버를 사용하기 위해서는 하나 이상의 웹 컨테이너가 존재해야 한다. 이의 설정 방법은 “JEUS

Web Container 안내서”의 “제2장 웹 컨테이너”를 참고한다.

10.2.3. 중앙 세션 서버의 튜닝

본 절에서는 중앙 세션 서버의 성능을 향상시키기 위한 튜닝 방법에 대해서 설명한다.

최고의 성능을 위해 중앙 세션 서버를 설정할 때 다음을 주의한다.

● resolution을 증가시키면 메모리는 좀 더 소비하지만 성능을 증가시킬 수 있다. 자세한 내용은 “10.2.2.

중앙 세션 서버의 설정”을 참고한다.

● "클라이언트와 중앙 세션 서버의 관계"에서 언급된 <check-level>의 값을 "set"으로 사용한다.

"modified"의 경우 추가적으로 세션의 변경을 엄격하게 검사하는 부하가 있으며 "all"의 경우 자주 중앙

세션 서버로 업데이트하는 부하가 있다.

● "Session Manager의 메모리 관리"에서 언급된 "-Djeus.sessionserver.memory.max" 옵션을 사용하지

않는다. 이 옵션을 사용할 경우 메모리에 있는 세션들의 크기를 검사하여, 검사 결과에 따라 추가적인

세션 passivation이 일어날 수 있기 때문이다.

● 성능을 향상 시키기 위해서는 passivation 타임아웃 값을 좀 더 크게 설정한다. 그러나 이렇게 하면 시스

템 메모리를 많이 소모하게 한다.

● check 타임아웃과 backup trigger에 설정값을 크게 설정한다. 그러면 backup 에 대한 호출이 적어지면

서 시스템이 빨라진다. 이 방식은 백업 기능을 훨씬 적게 사용한다.


10.2.4. JEUS 5에서 JEUS 6로 설정 변환

기존에 사용했던 JEUS 5의 세션 서버 설정과 JEUS6의 새로운 세션 서버 설정을 비교하여 변경된 부분을

위에서 예제로 소개했던 노드 johan과 johan1의 세션 클러스터링 구성을 예로 설명한다.

JEUS 5 설정 방법

다음은 JEUS 5에서의 설정 방법이다.

[예 10.4] 노드 johan : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan</name>

. . .

<session-server>

. . .



<session-manager>



<name>Session1</name>



<backup-name>Session2</backup-name>

. . .

</session-manager>

</session-server>

. . .

</node>

. . .

</jeus-system>

[예 10.5] 노드 johan1 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan1</name>

. . .

<session-server>

. . .



<session-manager>



<name>Session2</name>



<backup-name>Session1</backup-name>

. . .


</session-manager>

</session-server>

. . .

</node>

. . .

</jeus-system>

[예 10.6] 각 노드들의 웹 컨테이너 공통 : <<WEBMain.xml>>

<web-container>

. . .

<session-cluster>

. . .

<session-server>



<server-name>Session1</server-name>





<backup-server-name>Session2</backup-server-name>

</session-server>

</session-cluster>

. . .

</web-container>

이 외에 모든 jeus 스크립트 및 <command-option>에 다음과 같이 설정한다.

-Djeus.sessionmgr.Session1=johan

-Djeus.sessionmgr.Session2=johan2



[예 10.7] 노드 johan과 johan1의 공통 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan</name>

. . .

<session-server>





<type>primary</type>








. . .

</session-server>

. . .

</node>

<node>

<name>johan1</name>

. . .

<session-server>





<type>backup</type>




. . .

</session-server>

. . .

</node>

. . .

</jeus-system>

● JEUS 5 설정 중 <server-name>, <backup-server-name>의 설정이 없어지고 대신 세션 서버의 <type>

만 설정한다.

● JEUS 5 설정 중 <session-manager>의 tag가 없어지고 상위 tag와 합쳐졌다.

● JEUS 5 설정 중 WEBMain.xml에 설정하던 부분이 없어졌다.

● JEUS 5 설정 중 "-Djeus.sessionmgr.세션 서버이름=노드정보"를 추가할 필요가 없다.

● JEUS 6에서는 JEUSMain.xml의 정보를 클러스터링 하고자 하는 노드들끼리 동일하게 공유한다.

● JEUS 6에서는 추가적으로 세션 클러스터링에 참여하길 원하는 웹 컨텍스트에 한해 <distributable>을

true로 설정한다. 이에 대한 자세한 설명은 “JEUS Web Container 안내서”의 “2.3.7. Session”을 참고한

다.

10.3. 분산 세션 서버본 절에서는 중앙 세션 서버와 같은 기능을 제공하는 또 다른 세션 클러스터링 방식인 분산 세션 서버를

소개한다.

분산 세션 서버는 중앙 세션 서버와 같은 세션 클러스터링 기능을 제공하면서 확장성을 개선한 방식이다.

따라서, 대규모 클러스터링 환경에서 중앙 세션 서버에 비해 더 나은 성능을 발휘할 수 있다.

분산 세션 서버 방식은 대규모 클러스터링 환경에 적합한 세션 클러스터링 방식이다. 소규모 클러스터링

환경에서는 중앙 세션 서버 방식을, 대규모 클러스터링 환경에서는 분산 세션 서버 방식을 사용할 것을 권


장한다. 분선 세션 서버에 대한 자세한 내용은 “JEUS Web Container 안내서”의 “제2장 웹 컨테이너”를 참

고한다.

10.3.1. 분산 세션 서버의 개념

본 절에서는 분산 세션 서버의 기본적인 내용을 설명한다.

분산 세션 서버가 제공하는 기본 기능은 중앙 세션 서버와 동일하다. 여러 서블릿 엔진들로 구성된 클러스

터링 환경에서, 동일한 클라이언트에서 요청된 일련의 요청들이 특정 서블릿 엔진에서 처리되지 않더라

도 세션을 계속 유지해 주는 기능을 제공한다.

기능적인 측면은 중앙 세션 서버와 동일하나 동작 방식이 중앙 세션 서버와 달리 완전 분산식이어서 중앙

세션 서버에 비해 확장성이 더 용이하다.

분산 세션 서버가 가지는 특징을 정리하면 다음과 같다.

● 여러 개의 서블릿 엔진으로 구성된 클러스터링 환경에서 지속적인 세션 유지가 가능하게 한다.

● 바로 이전의 요청을 처리하던 서블릿 엔진이 다운되더라도 다른 서블릿 엔진들이 이후의 요청을 처리

할 때 세션이 끊기지 않도록 해준다.

● 분산식 프로토콜을 사용하기 때문에 클러스터링 규모가 커지더라도 확장성이 용이하다.

분산 세션 서버의 구조

분산 세션 서버는 세션 객체를 서비스하는 서버가 각각의 서블릿 엔진 또는 각각의 EJB 엔진(웹 컨테이너,

EJB 컨테이너)에 분산되어 있는 분산식 구조이다.

다음은 분산 세션 서버 방식을 사용하여 4개의 웹 컨테이너를 세션 클러스터링하는 구조이다.

[그림 10.2] 분산 세션 서버를 이용한 세션 클러스터링 구조

분산 세션 서버 방식은 클러스터링에 참여하는 모든 컨테이너 내에 독립적인 분산 세션 서버가 존재하고,

이들 분산 세션 서버들이 peer-to-peer로 다른 컨테이너의 분산 세션 서버와 통신하여 지속적인 세션 서비

스를 제공한다.


그림에 있는 화살표는 분산 세션 서버 간 소켓 연결을 의미하는데, 보통의 경우 연결이 필요없으며 세션

유지를 위해 다른 컨테이너와 통신할 필요가 있을 경우 연결을 맺고 유지한다. 또한 항상 모든 연결을 맺

는것을 의미하는 것이 아닌, 다른 모든것과 연결을 맺을 수 있는 "가능성"을 나타내는 그림이다. 장애가 발

생하지 않는 한 연결은 보통 하나씩만 가지게 된다.

다음은 웹 컨테이너의 서브 컴포넌트로 동작하는 분산 세션 서버의 내부 구조이다.

[그림 10.3] 분산 세션 서버 내부 구조

Local Web

Container

GetLocalSessio

n

backupSession/migrate

geRemoteSession

SCRemote Container/Message Handler

backupSession/passivateBackup

Backup Store

Remote Web Container


johan1_servlet_engine1

johan1_servlet_engine2

...

Cached Session

Session Manager

Cached Session

getBackupSession/migrate

backupSession/passivateLocal

Session Router (johan_servlet_engine1)

File DB

File DB

backupSession

getSession

getLocalStorageSession

getBackupStorageSession

● Session Manager

– 컨테이너의 세션 관리를 총괄하는 모듈이다. 로컬 메모리, 파일 및 다른 리모트 분산 세션 서버로부터

세션을 얻어오거나 관리한다.


– 로컬 웹 컨테이너는 getSession을 통해 Session Manager로부터 사용할 세션 객체를 얻어 온다.

로컬 메모리의 Cached Session, Local File Storage Session(getLocalStorageSession), Remote

Session(getRemoteSession)순으로 세션을 얻어온다.

– 메모리의 Cached Session은 일정주기(passivation 타임아웃)동안 사용하지 않으면 passivateLocal을

통해 파일에 저장되고 메모리에서 삭제된다.

– 수정된 세션은 리모트 백업이 있을 경우 SCRemoteContainer를 통해, 백업 서버로 정해진 다른 웹 컨

테이너의 분산 세션 서버로 in-memory 백업된다(backupSession). 이때 파일 storage설정이 있다면

Local File storage에도 동시에 저장된다.

참고

"수정된 세션"이란 <check-level>에 따라 다르게 적용된다. <check-level>이 "all"일 경우 항상 , "get"의

경우 getAttribute, "set"의 경우 setAttribute, removeAttribute, setMaxInactivateInterval의 세션 operation

이 발생했을 때 "수정된 세션"으로 판단한다. 자세한 설정은 "분산 세션 서버 기본 설정"을 참조한다.

– 다른 리모트 웹 컨테이너로부터 migrate 요청이 온다면 로컬 메모리의 Cached Session, Local File

storage순으로 세션을 반환해 준다. 이때 로컬에 존재하는 세션은 지움으로써 ownership을 다른 리모

트 분산 세션 서버에게 넘기게 된다.

● Backup Store

– 자신의 분산 세션 서버를 백업으로 선택한 다른 컨테이너의 분산 세션 서버가 주기적으로 전송하는

백업 세션 객체를 관리한다. 이 백업 세션 객체는 원본을 가지고 있는 컨테이너에 장애가 발생한 경우

대신하여 세션을 제공한다.

– 자신을 백업으로 지정한 리모트 웹 컨테이너가 전송하는 백업 세션을 받아 저장/관리한다(backupSes

sion, getBackupSession).

– 메모리에 Cached Session은 일정 주기(passivation 타임아웃)동안 사용하지 않으면 passivateBackup

을 통해 파일에 저장되고 메모리에서 삭제된다.

– backupToRemote : 로컬에서 수정된 세션 객체는 조건이 만족되면 지정된 리모트 분산 세션 서버로

백업된다.

여기서 조건은 2가지가 있다.

• 첫 번째는 check-to 설정으로 설정된 시간주기로 백업 프로세스가 기동된다.

• 두 번째는 backup-trigger 설정으로 설정된 개수만큼 수정된 세션 객체가 발생하면 백업 프로세스

가 기동된다. check-to와 backup-trigger의 관계는 or(또는)관계이다.

– 다른 리모트 웹 컨테이너로부터 backup store에 migrate요청이 온다면 로컬 메모리의Cached Session,

Local File Storage 순으로 세션을 반환한다.

● SCRemoteContainer

– 리모트 웹 컨테이너에 있는 세션들에 대해서 특정 operation을 할 경우 중재 역할을 해주는 모듈이다.

예) 리모트 웹 컨테이너로부터의 getSession(), removeSession()등


● MessageHandler

– 리모트 웹 컨테이너로부터 세션의 특정 operation 요청이 왔을 경우 가장 먼저 요청을 처리 및 분배해

주는 모듈이다.

분산 세션 서버의 동작 방식

분산 세션 서버 방식은 세션 라우팅을 기본으로 한다. 분산 세션 서버 방식이 사용하는 세션 Key는 다음과

같은 형식을 갖는다(웹 컨테이너에서 사용되는 예제이다).

<SessionID>.<primary-engine-name>

예) XXX.johan_servlet_engine1

“XXX”는 <SessionID>를 상징적으로 나타낸 것이다. 실제로 <SessionID>는 이보다 훨씬 긴 random string

형태이다. "johan_servlet_engine1"은 라우팅 정보를 의미한다. 노드는 johan이고 서블릿의 engine1을 의

미한다.

세션 라우팅을 지원하는 웹 서버를 앞단에 배치한다면 정상적인 경우 세션 객체가 존재하는 웹 컨테이너

로 요청이 라우팅 될 것이다. 따라서, 이러한 경우의 동작 방식은 세션 라우팅에 의한 세션 클러스터링과

동일하다(“JEUS Web Container 안내서”의 “제5장 Session Tracking” 참조).

[그림 10.4] 분산 세션 서버에 의한 fail-over 구조

2.forwordRequest

1.forwordRequest

WebContainer(engine1)

WebContainer(engine3)

WebContainer(engine2)3.getRemoteSession

4.getRemoteSession

Request Session Key : XXX.johan_servlet_engine1 Response Session Key : XXX.johan_servlet_engine3

Client

Web Server

웹 서버가 세션 라우팅을 지원할 수 없는 상황을 살펴보자. 웹 서버가 세션 라우팅을 지원하더라도 웹 서

버에 세션 라우팅 ID에 해당하는 웹 컨테이너로의 연결이 존재하지 않거나 해당 웹 컨테이너에 장애가 발


생하여 요청을 전달할 수 없는 경우가 여기에 해당한다. 이러한 경우 웹 서버는 보통 임의로 선택된 다른

웹 컨테이너로 요청을 전달한다. [그림 10.4]에 이러한 상황에서 분산 세션 서버의 동작 방식을 나타내었

다.

각 컨테이너는 세션 라우팅에 사용하는 세션 라우팅 ID를 하나씩 부여받는다. 이 ID는 웹 서버에 웹 컨테

이너가 접속할 때 웹 컨테이너를 구분하는 구분자로 사용된다. 세션 라우팅 ID는 설정에 의해 자동 생성된

다. [그림 10.4]의 3개의 웹 컨테이너는 다음과 같은 세션 라우팅 ID 및 백업이 할당되었다고 가정한다. 실

제 백업이 선택되어 지는 과정은 "분산 세션 서버의 백업 서버 선택 방식"을 참고한다.

● engine1의 ID : johan_servlet_engine1, 백업 : johan_servlet_engine2



다음은 [그림 10.4]의 상황에 대한 설명이다.

1. Request sessionKey값의 세션 라우팅 ID는 engine1 웹 컨테이너의 것이다. 이에 따라 웹 서버는 클라

이언트의 요청을 engine1 웹 컨테이너로 전달하는 것을 시도한다. 현재 engine1에 장애가 발생하였으

므로 이 시도는 실패한다.

2. 웹 서버는 나머지 2개의 웹 컨테이너 중 하나를 임의로 선택하여 클라이언트 요청을 전달하는 것을 시

도한다. 선택된 웹 컨테이너는 engine3이며 이 요청 전달은 성공하였다.

3. 웹 서버로부터 요청을 전달 받은 engine3는 세션 라우팅 ID를 분석한다. 분석 결과 이 요청을 처리할 세

션 객체는 engine1에 있으며 engine1이 primary 분산 세션 서버이고 engine2가 backup 분산 세션 서버

임을 알게 된다. 먼저 primary 분산 세션 서버가 engine1에 접속하여 세션 객체를 가져오려고 시도한다

(primary migration). engine1에 장애가 발생하였으므로 이 시도는 실패한다.

4. 백업 분산 세션 서버인 engine2로 다시 시도한다(backup migration). engine2는 백업한 세션 객체를

engine3로 넘긴다. 성공적으로 세션 객체를 가져온 engine3는 이후 클라이언트의 요청을 처리하여 응

답 메시지를 클라이언트에게 보낸다. 이 때 새로운 세션 Key를 작성하여 클라언트에게 보낸다. 이렇게

함으로써 클라이언트의 세션 Key가 변경되고 이 후 요청이 engine3로 오도록 한다. 새로운 세션 Key를

작성할 때는 세션 라우팅 ID부분만 자신의 것으로 치환한다.

분산 세션 서버 세션 클러스터링

중앙 세션 서버와 마찬가지로 분산 세션 서버를 가지고 있는 JEUS Manager 간에 클러스터링을 하면 분

산 세션 서버 간에도 클러스터링이 형성된다. 이렇게 되면 세션 데이터를 여러 서버에서 같이 사용할 수

있게 된다. 세션 클러스터링을 원할 경우 분산식에서도 JEUS 매니저의 클러스터링을 해야한다는것은 반

드시 명심해야 한다. JEUS 매니저 클러스터링에 대해서는 “제4장 JEUS 클러스터링”을 참고한다.

분산 세션 서버의 백업 서버 선택 방식

지금부터는 분산 세션 서버의 백업 선택 방식을 설명하겠다. 다음과 같은 기준으로 분산 세션 서버의 백업

을 선택한다. 다음 항목의 순서가 선택의 우선순위이다. 각 항목에 관한 설정의 세부사항은 "세부 분산 세

션 서버 설정"을 참고한다.


설명항목

자신의 분산 세션 서버가 선호하는 백업 분산 세션 서버 그룹을 지정할 수 있다.

백업을 선택할 때 이 정보가 가장 우선한다.

backup-group

자신의 분산 세션 서버와는 다른 machine, location에 있는 분산 세션 서버를 백

업으로 지정한다.

자신과 다른 location

위의 조건이 모두 동일하다면 최대한 적게 백업으로 지정된 분산 세션 서버를 백

업으로 선택한다. 백업 분산 세션 서버들이 최대한 분산되어서 선택되도록 하기

위함이다.

최대한 백업의 분산

다음 그림과 같이 분산 세션 서버가 세션 클러스터링된 상황을 생각해보자.

[그림 10.5] 분산 세션 서버의 백업 선택 알고리즘

FinancialServices

replication groupConsultingServices

replication groupPreferred backup group

B

C ZY

A

X

Different machine

WAS1X machine WAS2X machine

● A, B, C, X, Y, Z는 분산 세션 서버를 의미한다.

각각이 웹 컨테이너의 서로 다른 서블릿 엔진에 올라간다고 가정하자.

● A, X, Y는 WAS1X라는 물리적인 location에 존재한다.

● B, C, Z는 WAS2X라는 물리적인 location에 존재한다.

● A, B, C는 FinancialServices라는 논리적인 replication group이다.

● X, Y, Z는 ConsultingServices라는 논리적인 replication group이다.


● FinancialServices와 ConsultingServices은 서로 backup group관계이다. 즉, A, B, C는 backup-group으

로 ConsultingServices을 선택했고, X, Y, Z는 backup-group으로 FinancialServices를 선택했다.

그렇다면 A라는 분산 세션 서버의 백업 분산 세션 서버는 어느 것일까?

● A의 선호하는 백업 그룹은 ConsultingServices이다. ConsultingServices 그룹에 속하는 분산 세션 서버

는 X, Y, Z이다.

● X, Y, Z중에 A와 다른 location에 존재하는 Z가 있다.

● 따라서 선호하는 백업 그룹중에 A와 다른 location에 있는 Z가 A의 백업 분산 세션 서버가 된다.

이런 식으로 A ~ Z까지의 백업은 다음과 같이 정해진다.

A ~ Z까지의 백업을 선택하는 과정에서 선택을 누가 먼저 하느냐에 따라 백업으로 선택된 결과도 달라질

수 있다. 따라서 먼저 알파벳 순서로 모든 세션 클러스터링에 참여하는 분산 세션 서버들을 정렬한 후, 그

순서대로 백업 분산 세션 서버를 하나씩 결정하게 된다.

백업을 선택 할 때에는 하나씩만 선택을 하지만 여러 분산 세션 서버가 한 백업 분산 세션 서버를 선택할

수 있다(선택은 하나만 가능, 선택 받는것은 여러 개 가능, primary 분산 세션 서버로부터 backup 분산 세

션 서버로의 수학적 함수 관계라 생각하면 된다).

● A → Z

● B → X

X, Y가 모두 선택 가능하지만 알파벳 순서에 따라 X를 선택한다.

● C → Y

backup group과 location의 정보로 X, Y가 결정이 되지만 X는 이미 선택되어졌으므로 최대한의 분산을

위해 Y가 선택된다.

● X → B

● Y → C

● Z → A

10.3.2. 분산 세션 서버의 설정

분산 세션 서버를 설정하는 방법은 다음과 같이 JEUSMain.xml의 <node> 하위에 <session-router>를 추

가한다.

[예 10.8] 분산 세션 서버의 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

. . .

<session-router-config>


. . .

</session-router-config>

. . .

</node>

. . .

</jeus-system>

분산 세션 서버 기본 설정

<session-router-config>는 JEUSMain.xml 파일의 <node> 내에 하나만 존재해야 한다.

다음은 JEUSMain.xml 에 있는 분산 세션 서버 설정의 예이다.

[예 10.9] 분산 세션 서버 기본 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<engine-container>


<name>container1</name>

<engine-command>



</engine-command>

. . .

</engine-container>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

. . .


<thread-pool>

<min>10</min>

<max>20</max>

</thread-pool>







<default-file-db>

<startup-clear-to>86400000</startup-clear-to>

<passivation-to>-1</passivation-to>



</default-file-db>

<session-router>

. . . 

</session-router>


. . .

</node>

. . .

</jeus-system>


설명태그

분산식 세션 서버에서 사용되는 소켓 커넥션 처리를 위한 Thread Pool을 설정한

다.

<thread-pool>

컨테이너에 존재하는 분산 세션 서버 간 소켓 커넥션을 생성할 때 적용되는 타임

아웃 값이다.

<connect-timeout>

컨테이너에 존재하는 분산 세션 서버간 응답(reply) 메시지에 대해 적용되는 타

임아웃 값이다.

<read-timeout>

로컬 분산 세션 서버에서 세션 객체의 업데이트가 어느 정도 발생했을 때 백업

분산 세션 서버로 업데이트 세션 객체들을 백업할지를 설정한다. 이 설정에 지정

된 횟수만큼 로컬 분산 세션 서버에 업데이트가 발생하면 백업을 수행한다.

<backup-trigger>

백업 과정을 수행할 지를 체크하는 주기를 설정한다.<check-to>

이 설정에 지정된 시간마다 업데이트 된 세션 객체가 있는지를 조사하고 업데이

트된 세션 객체가 존재하면 백업을 수행한다. 추가적으로 백업 분산 세션 서버에

장애가 발생하였을 경우 alive check를 위한 주기 역할도 한다.

사용된 세션을 리모트 분산 세션 서버(Remote Web Container) 또는 로컬 파일

DB에 백업하기 전에 백업할 필요가 있는지를 체크하는 것이 필요하다.

<check-level>

이 설정은 백업의 필요성을 체크하는 기준을 정한다.

- set : 세션 객체에 setter를 호출한 경우에만 백업을 한다.

- get : 세션 객체에 getter를 호출한 경우에도 백업을 한다.

- all : 무조건 백업을 한다.


설명태그

업데이트된 로컬 세션 객체를 백업하는 방법으로는 백업 분산 세션 서버에 백업

하는 방법 외에, 로컬 파일 시스템으로 백업하는 방법도 있다. 이 설정을 통하여

업데이트된 세션 객체를 로컬 파일 시스템으로 백업한다.

<default-file-db>

실제 파일 백업은 컨테이너별로 수행되나 이 설정은 분산식 세션 클러스터링에

참여하는 모든 컨테이너(session-router설정)들에 디폴트로 동일하게 적용된다.

단, <session-router> 설정의 하위 element로 "file-db"가 설정될 경우 이 설정은

무시되고 <session-router>의 설정이 적용된다. 자세한 설정은 "세부 분산 세션

서버 설정"에서 설명한다.

분산식 세션 클러스터링에 참여할 컨테이너를 지정하고 해당 세션 서버에 대한

각종 속성을 설정한다. 반드시 하나 이상이 존재해야 하며, 자세한 설정은 "세부

분산 세션 서버 설정"에서 설명한다.

<session-router>

세부 분산 세션 서버 설정

세션 클러스터링에 참여할 분산 세션 서버에 대해 설정한다.

다음은 JEUSMain.xml에 웹 컨테이너에서 사용하는 4개의 <session-router>를 설정한 예이다.

johan 노드에는 johan_servlet_engine1, johan_servlet_engine2가 있으며 이 둘은 같은 was1x location, 같

은 FinancialServices replication group을 가지고 있다. 또한 같은 ConsultingServices이라는 선호하는 백

업 그룹을 가진다.

johan1 노드에는 johan1_servlet_engine1, johan1_servlet_engine2가 있으며 이 둘의 location은 was2x로

johan 노드와는 다른 location임을 알수 있다. 해당 그룹 또한 ConsultingServices로 johan 노드에서 설정

한 다른 분산 세션 서버와는 다른 그룹이며 johan노드에서 설정한 분산 세션 서버들을 선호하는 백업 그

룹(FinancialServices)으로 선택하였다.

[예 10.10] 세부 분산 세션 서버 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan</name>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

<engine-container>




<engine-command>



</engine-command>

. . .

</engine-container>

. . .


. . .

<session-router>

<engine-name>johan_servlet_engine1</engine-name>

<replication-group>FinancialServices</replication-group>

<backup-group>ConsultingServices</backup-group>

<location>was1x</location>

<file-db>





</file-db>

</session-router>

<session-router>


<replication-group>FinancialServices</replication-group>

<backup-group>ConsultingServices</backup-group>


<file-db>





</file-db>

</session-router>


. . .

</node>

. . .

<node>

<name>johan1</name>

<engine-container>



<engine-command>



</engine-command>


. . .

</engine-container>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

. . .


. . .

<session-router>

<engine-name>johan1_servlet_engine1</engine-name>

<replication-group>ConsultingServices</replication-group>

<backup-group>FinancialServices</backup-group>


. . .

</session-router>

<session-router>


<replication-group>ConsultingServices</replication-group>

<backup-group>FinancialServices</backup-group>


. . .

</session-router>


. . .

</node>

. . .

</jeus-system>

다음과 같은 세부 설정 항목이 있다.

● <engine-name>

– 세션 클러스터링에 참여할 컨테이너의 엔진 이름을 지정한다. 필수적으로 지정해야 하며, 엔진 이름

은 웹 컨테이너의 경우 <node-name>_servlet_<servlet-engine-name>, EJB 컨테이너의 경우 <node-

name>_ejb_<ejb-engine-name>식의 형태를 가진다.

– 다음은 설정에 대한 예제이다.

johan_servlet_engine1, johan_ejb_engine1


● <replication-group>

– 세션 클러스터링에 참여할 해당 분산 세션 서버의 논리적인 그룹 이름을 설정한다.

– 지정하지 않을 경우 이 값은 <node-name>으로 대체된다. 이 정보는 세션 클러스터링 환경에서 적절

한 백업 분산 세션 서버를 선택할 때 사용한다.

● <backup-group>

– 세션 클러스터링에 참여한 다른 분산 세션 서버 중 선호하는 백업 대상의 그룹 이름을 지정한다. 다른

분산 세션 서버 설정의 replication-group중에 선택한다.

– 지정하지 않을 경우 선호하는 그룹이 없다고 간주하며, 자신의 그룹과 다른 그룹을 우선적으로 선택

한다. 이 정보는 세션 클러스터링 환경에서 적절한 백업 분산 세션 서버를 선택할 때 사용한다.

● <location>

– 세션 클러스터링에 참여할 해당 분산 세션 서버의 물리적인 machine 이름 또는 location 정보를 설정

한다.

– 지정하지 않을 경우 이 엔진이 동작하는 hostname이 된다. 이 정보는 세션 클러스터링 환경에서 적

절한 백업 분산 세션 서버를 선택하는 데 사용된다.

● <file-db>

– 세션 객체를 파일 시스템에 백업할 때 사용하는 설정으로 기본적인 개념은 "분산 세션 서버 기본 설

정"에서 설명되었고, 여기에서는 하위 태그들의 의미를 살펴 본다.

– 컨테이너를 기동할 때 지정된 파일에 저장된 세션 객체들이 복구되는데, 만약 현재 시간과 파일의 last

modified time의 시간차가 <startup-clear-to> 설정에 지정된 값보다 크면 복구를 시도하지 않고 파일

의 내용을 모두 삭제한다.

– <path>는 백업 세션을 저장할 파일이름을 절대 경로로 지정한다. 기본값은 WEBMain.xml의 <session-

config>의 설정에 따라서 달라진다.

설명태그

JEUS_HOME/logs/sessiondb/ <engine-name>_1.fdbtrue

JEUS_HOME/logs/sessiondb/<context-name>_<context-path>1.fdbfalse

– 메모리에 존재하는 세션 객체를 <passivation-to>에 설정된 시간 이상 사용하지 않으면 삭제하고 대

신 file-db에 저장된 객체를 사용한다. 일정 시간 file-db를 운용하면 파일의 크기가 필요이상 커지게

된다.

– <min-hole>에 설정된 횟수 만큼 파일 I/O가 발생하거나, 현재 세션 객체 갯수 대비 파일 I/O 횟수가

<packing-rate>에 지정된 ratio를 넘어서면 파일 packing을 수행하여 필요이상 파일 크기가 늘어나

는 것을 방지한다.


10.3.3. JEUS 5에서 JEUS 6로 설정 변환

기존에 사용했던 JEUS5의 분산 세션 서버 설정과 JEUS6의 새로운 분산 세션 서버 설정을 비교하여 변경

된 부분을 설명한다.

위에서 예제로 소개했던 johan 노드의 johan_servlet_engine1, johan_servlet_engine2와 johan1 노드의

johan1_servlet_engine1, johan1_servlet_engine2의 Session Clustering 구성을 예로 사용한다.




<jeus-system>

. . .

<node>

<name>johan</name>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

. . .


. . .

<session-router>



<servlet-engine-name>engine1</servlet-engine-name>



<backup-session-router>

<node-name>johan1</node-name>


<container-base-port>3033</container-base-port>

</backup-session-router>


. . .

</session-router>

<session-router>






<node-name>johan1</node-name>




. . .

</session-router>


. . .

</node>

. . .

<node>

<name>johan1</name>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

. . .


. . .

<session-router>






<node-name>johan</node-name>





. . .

</session-router>

<session-router>






<node-name>johan</node-name>




. . .

</session-router>


. . .

</node>

. . .

</jeus-system>




<jeus-system>

. . .

<node>

<name>johan</name>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

<engine-container>



<engine-command>




</engine-command>

. . .

</engine-container>

. . .


. . .

<session-router>






. . .

</session-router>

<session-router>




. . .

</session-router>


. . .

</node>

. . .

<node>

<name>johan1</name>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

<engine-container>



<engine-command>



</engine-command>

. . .

</engine-container>

. . .


. . .

<session-router>





. . .

</session-router>

<session-router>




. . .

</session-router>


. . .

</node>

. . .

</jeus-system>

● JEUS 5 설정 중 <servlet-engine-name>이 JEUS 6에서는 <engine-name>으로 변경되었다. 기존에는

엔진 이름(short engine name)만 써주던 것을 JEUS 6에서는 노드, 엔진 이름을 혼합한 형식(full engine

name)으로 입력한다.

● JEUS 5 설정 중 <backup-session-router> 부분은 모두 없어진다. JEUS6에서는 백업이 자동으로 설정

된다.

● JEUS 5, 6 모두 JEUSMain.xml의 정보를 클러스터링할 노드들 간에 똑같이 공유한다.

● JEUS 6에서는 추가적으로 세션 클러스터링에 참여할 웹 컨텍스트에 한해 <distributable>을 true로 설

정한다. 이에 대한 자세한 설명은 “JEUS Web Container 안내서”의 “2.3.7. Session”을 참고한다.


제11장 Logging

본 장에서는 JEUS Logging 시스템에 대해 JEUS의 로거 구조 및 각 로거와 핸들러를 설정하는 방법, 로그

메시지의 내용에 대한 설명한다. JEUS 로거 시스템은 Java SE Logging API를 기반으로 구현되었기 때문

에 개발자는 이 API를 통해 JEUS Logging 시스템을 Customize할 수 있다.

11.1. 개요JEUS Logging은 JEUS 실행 중에 시스템에서 수행되었던 일련의 작업들에 대한 내용을 순서대로 보관,

기록하는 작업이다. 이를 통해서 시스템 관리자는 JEUS에서 일어난 여러 작업들에 대한 내용을 이해하

고, JEUS 실행 도중에 발생한 여러 에러 상황을 파악하여 그에 따른 대처를 할 수 있다.

JEUS는 시스템 및 애플리케이션에서 발생하는 여러 가지 상황들을 로그(log)를 통해 알려준다. JEUS는

Java SE에서 기본으로 제공되는 표준 Logging API(java.util.logging)를 사용한다. 따라서 Logging 시스템

의 구조나 설정 방식도 Logging API를 따르며 로거(logger), 핸들러(handler), Formatter 구조를 그대로 반

영하고 있다. 또한, 개발자가 Logging API를 이용하여 JEUS의 로거를 사용할 수 있다.

JEUS 로거는 노드와 엔진 컨테이너, 그리고 엔진 각각에 별도로 설정할 수 있다. 각 로거는 “jeus” 로거(여

기서 “jeus”는 로거의 이름)를 기준으로 생성되어 있다. JEUS Manager와 엔진 컨테이너들은 모두 “jeus”

로거를 기본적으로 생성한다. 하위에 생기는 여러 가지 모듈들은 jeus.ejb 등과 같이 jeus 하위의 로거를

생성해서 사용한다.

이런 여러 가지 로거 중에서 JEUS 설정 파일에서 설정 가능한 로거는 다음과 같다.

● jeus

● jeus.systemuser

● jeus.ejb

● jeus.servlet

● jeus.jms

● jeus 로거의 하위 로거

● java 로거

로거들에 대해 핸들러(handler)를 설정할 수 있는데, 이렇게 설정된 핸들러를 통해 로그 메시지를 기록한

다. JEUS에서는 로그 메시지 output의 형태에 따라 여러 가지 종류의 핸들러를 설정할 수 있는데, 가장 많

이 사용하는 것은 콘솔 핸들러(console handler)와 파일 핸들러(file handler)이다.

설명구분

로거를 통해 logging되는 로그 메시지를 콘솔 화면에 출력한다.콘솔 핸들러

제11장 Logging 169

설명구분

로거를 통해 logging되는 로그 메시지를 파일로 저장한다.파일 핸들러

이 외의 핸들러에 대한 설명과 각 로거에 대한 핸들러를 JEUS 설정 파일에 설정하는 방법에 대해서도 역

시 “11.3.1. 로거 설정”에서 설명한다. Logging 시스템에 대한 기본적인 이해는 Java SE의 Logging API를

참고한다.

11.2. JEUS 로거 기본 구조로거를 사용하기 위한 기본 개념을 먼저 설명하고 실제 설정 방법을 설명한다.

11.2.1. 기본 로거 파일 위치

파일 핸들러(file handler)를 사용할 경우, 파일 이름을 따로 지정하지 않는다면 각 JEUS 로거의 로그 메시

지는 정해진 위치에 파일을 생성한다. 그 외의 로그 파일은 Logging 설정을 하는 경우에만 생성된다.

다음은 각 로거의 기본 위치이다.

● 디폴트 컨테이너 사용할 경우

<node> 하위의 <system-logging>에 설정한다.

설명항목

JEUS Manager에서 남겨지는 로그는 JEUS_HOME\logs\<node-name> 디렉

터리에 JeusServer.log 파일로 남겨진다. 각 엔진 컨테이너의 로그는 JEUS

Manager에서 생성한 jeus 로거를 사용하여 로그를 남긴다.

jeus

각 엔진 컨테이너의 user log는 JEUS_HOME\logs\<node-name>\SYSTEM_EN

GINE 디렉터리에 UserLog.log 파일로 남겨진다.

jeus.systemuser

EJB 엔진의 로거는 실행되는 엔진 컨테이너 이름의 JEUS_HOME\logs\<node-

name>\SYSTEM_ENGINE\ejb 디렉터리에 error.log 파일로 남겨진다.

jeus.ejb

서블릿 엔진의 로거는 실행되는 엔진 컨테이너 이름의

JEUS_HOME\logs\<node-name>\SYSTEM_ENGINE\servlet\errorlog 디렉

터리에 error.log 파일로 남겨진다.

jeus.servlet

JMS 엔진의 로거는 실행되는 엔진 컨테이너 이름의 JEUS_HOME\logs\<node-

name>\SYSTEM_ENGINE\jms 디렉터리에 error.log 파일로 남겨진다.

jeus.jms

엔진 로거를 제외한 "jeus" 로거의 모든 하위 로거는 JEUS_HOME\logs\<node-

name> 디렉터리에 로거 이름을 가진 파일로 남겨진다.

jeus 로거의 하위 로거

예) jeus.jndi의 경우 jeus.jndi.log파일이 생성된다.


● 디폴트 컨테이너를 사용하지 않고 <engine-container> 하위의 <system-logging>에 설정한 경우

설명항목

각 엔진 컨테이너의 로그는 JEUS_HOME\logs\<node-name>\<node-

name>_<container-name> 디렉터리에 <node-name>_<container-name>.log

파일로 남겨진다.

jeus

각 엔진 컨테이너의 user log는 JEUS_HOME\logs\<node-name>\<node-

name>_<container-name> 디렉터리에 UserLog.log 파일로 남겨진다.

jeus.systemuser

EJB 엔진의 로거는 JEUS_HOME\logs\<node-name>\<node-name>_<con

tainer-name>\ejb 디렉터리에 error.log 파일로 남겨진다.

jeus.ejb

서블릿 엔진의 로거는 JEUS_HOME\logs\<node-name>\<node-

name>_<container-name>\servlet\errorlog 디렉터리에 error.log 파일로 남겨

진다.

jeus.servlet

JMS 엔진의 로거는 JEUS_HOME\logs\<node-name>\<node-name>_<con

tainer-name>\jms 디렉터리에 error.log 파일로 남겨진다.

jeus.jms


name>_<container-name> 디렉터리에 로거 이름을 가진 파일로 남겨진다.



● 디폴트 컨테이너를 사용하지 않는데 <node> 하위의 <system-logging>에 설정한 경우

설명항목

JEUS Manager에서 남겨지는 로그는 JEUS_HOME\logs\<node-name> 디렉

터리에 JeusServer.log 파일로 남겨진다.

jeus

각 엔진 컨테이너의 user log는 JEUS_HOME\logs\<node-name>\SYSTEM_EN

GINE 디렉터리에 UserLog.log 파일로 남겨진다.

jeus.systemuser

EJB 엔진의 로거는 실행되는 엔진 컨테이너 이름의 JEUS_HOME\logs\<node-

name>\SYSTEM_ENGINE\ejb 디렉터리에 error.log 파일로 남겨진다.

jeus.ejb

서블릿 엔진의 로거는 실행되는 엔진 컨테이너 이름의

JEUS_HOME\logs\<node-name>\SYSTEM_ENGINE\servlet\errorlog 디렉

터리에 error.log 파일로 남겨진다.

jeus.servlet

JMS 엔진의 로거는 실행되는 엔진 컨테이너 이름의 JEUS_HOME\logs\<node-

name>\SYSTEM_ENGINE\jms 디렉터리에 error.log 파일로 남겨진다.

jeus.jms


name> 디렉터리에 로거 이름을 가진 파일로 남겨진다.




참고

디폴트 컨테이너의 경우는 로거 설정을 하더라도 무시된다. 매니저와 같은 JVM이기 때문에 매니저

의 로거를 공유한다.

만약 매니저에는 로거 설정을 하지 않고 디폴트 컨테이너에만 로거 설정을 한 경우 설정이 적용되지

않는다. 이때 로거는 콘솔 핸들러만 사용해서 출력되고 레벨은 INFO이다.

11.2.2. 로그 포맷

JEUS에서 제공되는 로그의 포맷은 다음과 같다.

● [시간] [레벨] [버전] [Logging되는 스레드 정보] [로그 메시지 ID] 로그 메시지

설명항목

'년.월.일 시간:분:초' 의 형식으로 출력된다.시간

로그 레벨이 그에 매핑되는 숫자로 출력된다.레벨

- 0: SEVERE

- 1: WARNING

- 2: INFO

- 3: CONFIG

- 4: FINE

- 5: FINER

- 6: FINEST

- 7: ALL

JEUS의 빌드 버전을 표시한다.버전

Logging하는 프로세스(노드 또는 컨테이너 이름)와 스레드 번호로 표현되며,

이 둘은 하이픈('-')으로 구분된다. 스레드 정보가 같은 로그는 같은 스레드에

서 Logging한 메시지이다.

Logging되는 스레드 정보

로그를 출력하는 각 모듈에 대한 정보로, 모듈 이름과 메시지 번호로 표현되

며, 이 둘은 하이픈('-')으로 구분된다. 각 모듈에 해당하는 이름은 “11.2.5. 로

그 메시지 모듈 이름”을 참고한다.

로그 메시지 ID

실제 로그 메시지를 출력한다.로그 메시지

다음은 실제 JEUS 서버에 출력되는 로그 메시지의 예이다.


[예 11.1] 로그 메시지 출력

[2007.01.29 19:43:53][2][b007] [johan-10] [JNSS-0022]

JEUS naming server successfully exported.

...

[2007.01.29 19:43:54][2][b007] [johan-10] [JMX-0046]

Create Jeus System MBeanServer

...

[2007.01.29 19:44:23][0][b007] [johan-10] [MGR-0241]

JeusServer is Ready

우선, 첫 번째 로그 메시지는 2007년 1월 29일 오후 7시 43분 53초에 출력된 레벨 2(INFO 레벨)의 메시

지이며, 현재 실행되고 있는 JEUS의 버전은 build version b007라는 것을 알려준다. 또한 이 로그는 'jo

han'이라는 노드에서 10번 스레드에 의해 Logging되었고, JNSS(JNSServer에 해당하는 모듈 이름)모

듈의 22번 메시지가 출력되었음을 알 수 있다.

실제 로그 메시지는 JEUS의 Naming Server가 성공적으로 export되었음을 알려준다. 두 번째, 세 번째

로그 메시지 역시 첫번째 메시지와 같은 프로세스에서 Logging되었음을 할 수 있으며, 각각 JMX와

MGR(JEUSManager에 해당하는 모듈 이름)의 메시지가 출력되었음을 알 수 있다. 실제 로그의 내용도

JEUS의 MBean 서버와 JEUS 서버가 성공적으로 실행되었음을 알려주고 있다.

11.2.3. 로거 리스트

● EJB 관련

설명구분

EJB Home/Object stub 관련 로거jeus.ejb.bean

EJB 클러스터링 관련 로거jeus.ejb.cluster

EJB stub compiler 관련 로거jeus.ejb.compiler

MDB와 리소스 어댑터 관련 로거jeus.ejb.connector

EJB 컨테이너 관련 로거jeus.ejb.container

EJB 엔진 관련 로거jeus.ejb.ejbserver

EJB CORBA 연동 관련 로거jeus.ejb.interop

CMP 관련 로거jeus.ejb.persistence

EJB QL 관련 로거jeus.ejb.schema

EJB Timer 관련 로거jeus.ejb.timer

EJB Transaction & Synchronization 관련 로거jeus.ejb.transaction

EJB classftp 관련 로거jeus.ejb.webserver

기타 로거jeus.ejb.util


● JPA 관련

설명구분

JPA 모듈의 최상위 로거jeus.persistence

TopLink Essentials (default provider)의 최상위 로거jeus.persistence.provider

JPA에 대한 컨테이너 로거jeus.persistence.container

● 서블릿 관련

설명구분

서블릿 공통 모듈 관련 로거jeus.servlet.common

connector 관련 로거jeus.servlet.connection

NIO connector 관련 로거jeus.servlet.connector

Deploy 관련 로거jeus.servlet.deployment

서블릿 주요 처리 과정 관련 로거jeus.servlet.engine

필터 관련 로거jeus.servlet.filter

JSP 관련 로거jeus.servlet.jsp

서블릿 Listener 관련 로거jeus.servlet.listener

클래스 로더 관련 로거jeus.servlet.loader

프로퍼티 관련 로거jeus.servlet.property

JEUS에서 제공하는 서블릿 관련 로거jeus.servlet.servlets

유틸리티에서 사용하는 로거jeus.servlet.util

Class FTP 서비스에서 사용하는 로거jeus.webserver

● Session Manager 관련

설명구분

Session Manager의 최상위 로거, 공통적으로 사용되는 로거jeus.session

중앙 Session Manager의 로거jeus.session.central

분산 Session Manager의 로거jeus.session.distributed

● 웹 서비스 관련

– JAX-RPC/SAAJ 로거

설명구분

jeus.webservices.client 패키지(client invocation framework) 관련 로거jeus.webservices.client

SOAP serialize/deserialize 관련 로거jeus.webservices.encoding


설명구분

SAAJ 및 SOAP 메시지 관련 로거jeus.webservices.message

WSDL 처리 관련 로거jeus.webservices.wsdl

그 외 웹 서비스 관련 로거jeus.webservices

– UDDI 로거

설명구분

Database processing 관련 로거jeus.uddi.datastore

UDDI API message processing 관련 로거jeus.uddi.function

Registry Server Engine 관련 로거jeus.uddi.judy

Transport layer, Reqeust/Response processing, Registry 엔진 관련 로

거

jeus.uddi.registry

– WS-* 로거 (JAX-RPC 기반)

설명구분

ws-security 관련 로거jeus.webservices.wss

– 기타

설명구분

EWS(JSR109)에 사용되는 DD 바인딩 관련 로거jeus.xml.binding.webser

vicesHelper

● 트랜잭션 관련

설명구분

트랜잭션 매니저 전반적으로 사용하는 로거jeus.transaction

recovery에 사용되는 Resource Factory 관련 로거jeus.transaction.logging

OTS 관련 로거jeus.transaction.ots

트랜잭션 recovery 작업 내용을 기록하는 로거jeus.transaction.recovery

● Security 관련

설명구분

JEUS Security 관련 로거jeus.security

JEUS Security 로그인 서비스 관련 로거jeus.security.impl.login

JEUS Security 유틸리티 관련 로거jeus.security.util


● 기타

설명구분

JEUS 클래스 로딩 관련 로거jeus.classloader

JEUS 노드 클러스터링 관련 로거jeus.clustering

J2EE Connector 관련 로거jeus.connector

XML 컨버터 관련 로거jeus.converter

Deployment Descriptor Initializer 관련 로거jeus.ddinit

애플리케이션 Deploy 관련 로거jeus.deploy

JEUS Network I/O library 관련 로거jeus.io

JDBC Connection Pool 관련 로거jeus.jdbc

JMX 관련 로거jeus.jmx

JNDI 관련 로거jeus.jndi

JNLP 관련 로거jeus.jnlp

JTmax 관련 로거jeus.jtmax

JMX MBean Framework 관련 로거jeus.management

JEUS Network API 관련 로거jeus.net

JEUS 통합 포트 관련 로거jeus.netutil

JEUS 노드 콘트롤러 관련 로거jeus.nodecontroller

JEUS RMI 관련 로거jeus.rmi

JEUS 스케줄러 관련 로거jeus.scheduler

JEUS 서비스 MBean 관련 로거jeus.service

11.2.4. 사용자 로거

JEUS의 각 엔진 컨테이너마다 제공되는 사용자 로거(user logger)는 개발자가 별도의 로거를 사용할 필

요 없이 JEUS에서 제공하는 로거를 사용할 수 있도록 한다. Java SE Logging API의 java.util.logging.logger

API를 사용해서 사용자 로거를 사용할 수 있다.

11.2.5. 로그 메시지 모듈 이름

JEUS에서 제공되는 로그 메시지는 여러 가지 정보를 제공하고 있다. 그 중 로그 메시지의 형식에 따라 모

듈의 정보를 출력하는 로그 메시지 정보에서는 각 모듈의 이름을 확인할 수 있다. 본 절에서는 로그에 출

력되는 각 모듈 이름과 이에 해당하는 실제 모듈들에 대해 설명한다.


모듈 이름모듈 정보

중앙 집중식 세션 서버C_Session

ConnectorConnector

분산식 세션 서버D_Session

애플리케이션 DeployDeploy

EJB 엔진EJB

JMXJMX

JNDI 공통JNDI.Common

JNDI ContextJNDI.Context

JNS(Local Naming Server)JNDI.Local

JNLPJNLP

JNS 서버JNSS

jtmaxJTMAX

매니저(Manager)MGR

Monitor

Monitoring

JEUS 네트워크NET

JEUS 네트워크NIO

OTS

스케줄러Scheduler

JEUS SecuritySecutiry

Session

트랜잭션 매니저TM

트랜잭션 매니저 recoveryTMRecovery

UDDIUDDI

서블릿 엔진WEB

WebTWebT

WebtoBWebtobLight

웹 서비스 SecurityWSS

웹 서비스WSVC

ConverterXML


11.3. JEUS Logging 설정본 절에서는 JEUS에서 Logging에 대한 설정 방법과 커스터마이즈(customization) 방법 등을 주로 설명한

다.

11.3.1. 로거 설정

다음은 JEUS 설정 파일에 설정 가능한 로거에 대한 설명이다.

설명항목

JEUS 시스템에서 사용하는 최상위의 로거이다. JEUSMain.xml <node> 항

목의 <system-logging> 항목에서는 JEUS Manager JVM의 jeus 로거를 설정

jeus

하고 <engine-container> 항목의 <system-logging>은 해당 엔진 컨테이너

JVM의 jeus 로거를 설정한다. 엔진 컨테이너에서는 <engine-container> 항

목의 <system-logging>항목이 없다면 <node> 항목의 <system-logging> 항

목에서 설정한 <level>을 따르게 된다.

엔진 컨테이너의 user 로거에 해당한다. 따라서 JEUSMain.xml <engine-

container> 항목의 <user-logging>에 설정할 수 있다.

jeus.systemuser

EJB 엔진에서 사용하는 로거로, <node>나 <engine-container>의 <system-

logging> 항목에 설정할 수 있고 해당 EJB 엔진의 <engine-command>의

<system-logging>에 설정할 수 있다.

jeus.ejb

서블릿 엔진에서 사용하는 로거로, <node>나 <engine-container>의 <system-

logging>항목에 설정할 수 있고 해당 서블릿 엔진의 <engine-command>의


jeus.servlet

JMS 엔진에서 사용하는 로거로, <node>나 <engine-container>의 <system-

logging>항목에 설정할 수 있고 해당 JMS 엔진의 <engine-command>의


jeus.jms

설정한 로거에 해당하는 서비스와 관련된 로거로, <node>나 <engine-contain

er>의 <system-logging>항목에 설정할 수 있다.


이들 로거 중 jeus를 제외한 다른 로거들은 설정하지 않으면 상위 로거의 핸들러(handler)를 사용해서 로

그 메시지를 출력한다. 또한 jeus 로거는 설정되지 않으면 콘솔 핸들러(console handler)를 사용한다. 따라

서 JEUSMain.xml에 아무런 로거 설정이 되어 있지 않다면, JEUS Manager와 모든 엔진 컨테이너의 로그

메시지가 JEUS Manager의 콘솔창으로 보이게 된다. 이때 레벨(level)은 INFO이다. jeus 로거는 기본적으

로 상위 로거의 핸들러를 사용하지 않는다.

참고

엔진 컨테이너에 로거 설정을 하지 않으면 매니저에 설정한 로그 레벨을 따르게 된다. 이때 핸들러는

콘솔 핸들러이고 핸들러의 레벨은 기본값인 FINEST이다.


매니저에서 콘솔 핸들러의 레벨을 설정하였더라도 엔진 컨테이너의 콘솔 핸들러의 레벨은 FINEST

로 매니저의 설정을 따르지 않는다. 매니저에 로그 설정에 따라서 콘솔창에 모든 레벨의 엔진 컨테이

너 로그가 출력될 수도 있다.

다음은 로거의 설정에 예로 JEUSMain.xml의 <system-logging> 항목의 설정을 통해 Logging 설정을 할

수 있다. JEUS에서는 WebAdmin을 통해 설정하는 것을 권장한다.

[예 11.2] 로거 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan</name>

. . .

<engine-container>


. . .

<engine-command>

<type>ejb</type>


</engine-command>

<engine-command>



</engine-command>

. . .



<system-logging>



<level>INFO</level>

<handler>

<file-handler>

<name>fileHandler</name>

<valid-hour>1</valid-hour>

</file-handler>

</handler>

</system-logging>



<system-logging>

<name>jeus.ejb</name>

<level>FINEST</level>

</system-logging>

. . .

</engine-container>

. . .




<user-logging>

<level>FINE</level>

<use-parent-handlers>true</use-parent-handlers>

<handler>

<smtp-handler>

<name>smtpHandler</name>

<level>SEVERE</level>

<smtp-host-address>mail.com</smtp-host-address>

<from-address>[email protected]</from-address>

<to-address>[email protected]</to-address>

<send-for-all-messages>

false

</send-for-all-messages>

</smtp-handler>

</handler>

</user-logging>



<system-logging>

<level>FINE</level>

<handler>

<console-handler>

<name>consoleHandler</name>

<level>INFO</level>

</console-handler>

<file-handler>


<level>FINE</level>


</file-handler>

</handler>

</system-logging>



<system-logging>

<level>FINE</level>

<handler>

<console-handler>


<level>INFO</level>

</console-handler>

<file-handler>


<enable-rotation>true</enable-rotation>

<rotation-count>50</rotation-count>

<valid-size>10240</valid-size>


<append>false</append>

</file-handler>

</handler>

</system-logging>

</node>

. . .

</jeus-system>

다음은 <system-logging> 하위 설정 헝목에 대한 설명이다.

설명항목

로거의 이름을 설정한다. <node>나 <engine-container> 내에 이 설정이 생략

된 경우에는 jeus 로거이다. <engine>내에 설정이 되어 있는 경우에는 무시

한다.

<name>

로거의 레벨(level)을 설정한다. 이 레벨 이하의 메시지만 로거를 통해 출력될

수 있다.

<level>

이 레벨의 값으로는 logging API의 레벨인 SEVERE(FATAL), WARNING(NO

TICE), INFO(INFOMATION), CONFIG, FINE(DEBUG), FINER, FINEST, ALL

이 올 수 있다. 기본 설정은 INFO이다.

로거가 자신의 핸들러 뿐만 아니라 상위 로거의 핸들러를 사용할 것인지의

여부를 설정한다.

<use-parent-handlers>

기본값은 true이지만 "jeus" 로거의 경우는 JEUS의 최상위 로거이기 때문에

false이다. 또한 자신의 핸들러를 설정하지 않고 이 값을 false로 설정할 경우

상위 핸들러를 사용할 수 있도록 이 값을 true로 바꿔준다.

로거가 로그 메시지를 핸들러에게 보내기 전에 수행하는 필터링(filtering)에

사용할 클래스를 지정한다. 여기에 지정된 클래스는 lib/application 디렉터리

의 jar 파일 내에 포함되어야 한다.

<filter-class>

로거가 사용할 핸들러를 지정한다. 이 항목이 설정되어 있지 않다면 콘솔 핸

들러(console handler)가 기본적으로 사용된다.

<handler>

<handler>에는 콘솔 핸들러, 파일 핸들러, SMTP 핸들러, 소켓 핸들러, 사용자 핸들러가 있으며, 각 핸들

러에 대해 다음과 같은 하위 항목들이 있다.

● <console-handler>

콘솔 핸들러로, 화면으로 로그 메시지를 출력하는 핸들러이다.

다음과 같은 기본적인 핸들러 설정만 가지고 있다.

설명항목

핸들러가 툴에서 보여질 때 사용할 이름을 지정한다. 이름은 하나의 로거 내에서

유일하기만 하면 된다. 만약 지정되어 있지 않으면 클래스 이름과 Hash Code)

이름이 대체된다.

<name>


설명항목

핸들러가 출력할 메시지의 레벨을 지정한다. 즉, 로거를 통과한 로그 메시지가

이 로거가 사용하는 각각의 핸들러에게 전달되는데, 이 핸들러의 레벨에 부합하

는 로그 메시지만 이 핸들러에 의해 출력된다.

<level>

기본값은 FINEST로 로거를 통과하는 모든 로그 메시지가 핸들러에 의해 출력되

도록 되어 있다.

핸들러가 출력하는 문자열의 encoding을 지정한다. 기본은 system encoding으

로 설정되어 있다.

<encoding>

핸들러가 로그 메시지를 출력하기 전에 수행할 필터링에 이용되는 클래스이다.

로거의 <filter-class>와 마찬가지로 lib/application에 이 클래스를 포함한 jar 파일

이 존재해야 한다.

<filter-class>

● <file-handler>

파일 핸들러로, 파일로 로그 메시지를 출력하는 핸들러이다.

<console-handler>의 설정 이외에 다음과 같은 설정을 가지고 있다.

설명항목

이 핸들러가 출력할 파일의 이름을 지정한다. 절대 경로로 되어 있다면 그 경로

로 파일이 생성되고 상대 경로라면 각 로거의 기본 경로를 기준으로 한 상대 경

<file-name>

로로 인식한다. 이 설정을 하지 않으면 각 로거별로 지정된 경로로 파일을 생성

해서 로그 메시지를 출력한다.

핸들러가 로그 파일 Rotation기능을 사용할 것인지 설정한다. 기본값은 false로

Rotation기능을 사용하지 않는다.

<enable-rotation>

핸들러가 로그 파일 Rotation기능을 사용할 때만 의미가 있다.<rotation-count>

핸들러가 로그 파일 rotation기능을 사용할 때만 의미가 있다.<rotation-dir>

핸들러가 출력할 파일을 시간마다 따로 생성할 경우에 사용한다. 둘 중 하나만

사용할 수 있는데, valid-day는 날짜별로, valid-hour는 시간별로 파일을 변경한

<valid-day>, <valid-

hour>

다. valid-hour는 24의 약수(예: 3, 6)이거나 24로 나눈 나머지가 약수(예: 27, 30)

인 값을 지정한다. 파일 이름의 형식은 valid-day의 경우 파일 끝에 _YYYYMMDD

가 붙고, valid-hour의 경우 _YYYYMMDD_HH 가 붙는다. 이때 HH는 파일 로그

의 시작 시간이다. 이 핸들러가 로그 파일 Rotation기능을 사용한다면 이 설정값

의 의미가 달라진다.

핸들러가 로그 파일 Rotation기능을 사용할 때만 의미가 있다.<valid-size>

파일로 출력할 때 사용할 버퍼(buffer)의 크기를 지정한다. 버퍼가 클수록 Logging

의 성능은 좋아지지만 예상치 못한 상황으로 JEUS가 종료될 때에는 그 버퍼 크

기만큼 로그가 손실된다.(기본값: 1024KB)

<buffer-size>

서버를 기동한 뒤 로그를 파일로 출력하려고 할 때 이미 같은 이름의 파일이 존

재하면 덮어쓸지, 파일끝에 추가할지를 결정한다.

<append>


설명항목

기본값은 true로 파일 끝에 추가한다. 이 핸들러가 로그 파일 Rotation기능을 사

용한다면 이 설정값의 의미가 달라진다.

● <smtp-handler>

SMTP 핸들러로, 로그 메시지를 이메일(e-mail)로 전송하는 핸들러이다. 하나의 로그 메시지가 하나의

이메일로 전송된다.


설명항목

이메일을 보낼 호스트(host)의 주소를 지정한다.<smtp-host-address>

이메일을 보내는 사람의 주소를 지정한다.<from-address>

이메일을 받는 사람의 주소를 지정한다.<to-address>

이메일을 참조로 받는 사람의 주소를 지정한다.<cc-address>

이메일을 숨은 참조로 받는 사람의 주소를 지정한다.<bcc-address>

모든 메시지를 SMTP 핸들러로 보낼지를 결정한다. 만약 false이면 JEUS 시스

템에서 이메일로 전송하기로 결정되어 있는 메시지만 이 핸들러를 사용해서 보

내진다. 현재 이 설정은 jeus.systemuser 로거에만 유효하다.

<send-for-all-mes

sages>

● <socket-handler>

소켓 핸들러로, 로그 메시지를 소켓(socket)으로 전송하는 핸들러이다.


설명항목

핸들러가 접속할 머신(machine)의 IP 주소를 지정한다.<address>

핸들러 접속할 머신의 port를 지정한다.<port>

● <user-handler>

사용자 핸들러로, 사용자가 생성한 핸들러 클래스를 지정하는 항목이다.


설명항목

사용자가 만든 핸들러의 클래스를 지정한다. 이 클래스는 lib/application 디렉터

리의 jar 파일에 포함되어 있어야 한다. 또한 이 클래스는 logging API의 java.util.log

ging.Handler를 상속받고 jeus.util.logging.JeusHandler를 구현해야 한다.

<handler-class>

jeus.util.logging.JeusHandler의 setProperty()에 사용되는 Map 객체에 들어갈

프로퍼티를 지정한다.

<handler-property>


설명항목

핸들러가 사용할 Formatter(formatter) 클래스를 지정한다. 이 클래스도 lib/appli

cation 디렉터리의 jar 파일에 포함되어 있어야 한다. 또한 jeus.util.logging.JeusFor

<formatter-class>

matter 인터페이스를 구현해야 한다. 기본값은 JEUS에서 사용하는 jeus.util.log

ging.SimpleFormatter이다.

jeus.util.logging.JeusFormatter의 setProperty()에 사용되는 Map 객체에 들어갈

프로퍼티를 지정한다.

<formatter-property>

11.3.2. 로그 파일 Rotation 설정

JEUS는 JEUS가 시작될 때, 혹은 JEUS 운영 중에 설정한 시간이 되거나 파일사이즈를 넘으면 자동으로

이전에 Logging하던 파일의 이름은 바꾸고 새로 출력할 로그들은 원래의 로그 파일에 계속 Logging할 수

있도록 로그 파일 Rotation 기능을 제공한다.

valid-day, valid-hour, valid-size 설정에 따라 Rotation 한다. Rotation의 조건이 되는 3항목 중 아무 것도

설정되어 있지 않으면 로그 파일 사이즈가 1024KB가 되면 Logging하던 파일의 이름을 바꾸고 이 후에

Logging되는 파일은 이전에 Logging하던 파일에 새로 Logging한다.

다음은 로그 파일 Rotation에 대한 예제로 JEUSMain.xml의 <file-handler> 항목의 설정을 통해 Logging

설정을 할 수 있다. WebAdmin을 통해 설정할 수도 있다.

[예 11.3] 로그 파일 Rotation 설정 : <<JEUSMain.xml>>

<jeus-system>

. . .

<node>

<name>johan</name>

. . .

<engine-container>


. . .



<system-logging>

<level>FINE</level>

<handler>

<console-handler>


<level>INFO</level>

</console-handler>

<file-handler>







</file-handler>

</handler>

</system-logging>

</engine-container>

. . .



<system-logging>

<level>FINE</level>

<handler>

<console-handler>


<level>INFO</level>

</console-handler>

<file-handler>




<valid-size>10240</valid-size>


</file-handler>

</handler>

</system-logging>

</node>

. . .

</jeus-system>

<file-handler> 의 하위 항목 중 로그 파일 Rotation과 관련된 설정 다음과 같다.

<

설명항목

이 핸들러가 로그 파일 Rotation기능을 사용할 것인지 설정한다. 기본값은 false

로 rotation기능을 사용하지 않는다. 로그 파일 Rotation기능을 사용하게 되면 파

<enable-rotation>

일에 로그를 출력할 때 하나의 파일에만 출력하고 valid-day나 valid-hour, valid-

size 중 하나의 설정에 따라서 파일 이름이 바뀌게 되고 그 이후에 출력되는 로그

에 대해서는 다시 처음에 Logging을 하던 파일에 새로 출력이 된다. enable-rotation

을 true로 설정하고 valid-day나 valid-hour, valid-size를 설정하지 않으면 기본적

으로 valid-size의 값이 1024 KB로 동작하게 되고 로그 파일 사이즈가 1024 KB

가 되면 원래 Logging하던 파일 이름 뒤에 인덱스를 붙여서 새로운 이름으로 바

뀌게 된다.

핸들러가 Rotation을 한 백업 로그 파일을 몇 개나 보관할지 여부를 설정한다.<rotation-count>

핸들러가 Rotation을 한 백업 로그 파일을 어디에 저장할지를 설정한다. 기본값

은 현재 파일 Logging을 하고 있는 디렉터리이다.

<Rotation-dir>


설명항목

핸들러가 출력한 로그 파일을 정해진 시간이 되면 로그 파일의 이름을 바꾼다.

둘 중 하나만 사용할 수 있는데, valid-day는 날짜별로, valid-hour는 시간별로 파

일을 변경한다.

<valid-day>,

<valid-hour>

valid-hour는 24의 약수(예: 3, 6)이거나 24로 나눈 나머지가 약수(예: 27, 30)인

값을 지정한다. 바뀔 파일 이름의 형식은 valid-day의 경우 파일 끝에 _YYYYM

MDD가 붙고, valid-hour의 경우 _YYYYMMDD_HH 가 붙는다. 이때 HH는 로그

파일에 마지막으로 Logging한 시간이다.

핸들러가 출력한 로그 파일이 정해진 사이즈가 되면 로그 파일의 이름을 바꾼다.<valid-size>

바뀔 파일 이름의 형식은 파일 끝에 _xxxxx 가 붙는다. 이때 xxxxx는 1부터 99999

까지의 정수이다. 기본값은 1024 KB로 로그 파일 Rotation기능을 사용하고 valid-

day나 valid-hour, valid-size의 설정값이 없을 때 이 값으로 동작한다.

서버를 기동한 뒤 로그를 파일로 출력하려고 할 때 이미 같은 이름의 파일이 존

재하면 이전에 Logging하던 파일의 이름을 valid-day, valid-hour, valid-size 설정

<append>

에 따라 바꾸고 앞으로 Logging하게 될 로그 메시지는 계속 하나의 파일에만 출

력한다.

기본값은 true로 아직 설정한 조건이 되지 않았으면 파일 끝에 추가한다.

11.3.3. 표준 출력과 표준 에러를 로그 형식으로 출력 설정

JEUS에서는 표준 출력과 표준 에러를 JEUS 로그 형식으로 출력하는 기능을 제공한다. JEUS에서 기본

으로 사용하는 포맷을 이용하여 JEUS 로거와 비슷한 형식으로 표준 출력와 표준 에러를 출력할 수 있다.

다음은 표준 출력과 표준 에러를 JEUS 로그 형식으로 출력하는 예제로 JEUSMain.xml에 <log-stdout-to-

raw-format> 항목을 설정한다.

[예 11.4] 표준 출력과 표준 에러를 JEUS 로그 형식으로 출력 : <<JEUSMain.xml>>

<jeus-system>

<node>

. . .

<log-stdout-to-raw-format>true</log-stdout-raw-format>

<engine-container>

. . .

<log-stdout-to-raw-format>false</log-stdout-raw-format>

</engine-container>

</node>

</jeus-system>

설명항목

표준 출력과 표준 에러 메시지를 raw format 그대로 출력할지 로그 형식

으로 출력할지를 설정한다.

<log-stdout-to-raw-format>


설명항목

기본값은 true로 raw format 그대로 출력한다. 엔진 컨테이너의 경우에

해당 설정이 없으면 매니저의 설정을 따른다.

이 기능을 사용하면 표준출력은 다음과 같은 포맷으로 출력된다.

● [시간] [레벨] [버전] [Logging되는 스레드 정보] [STDOUT/STDERR] 메시지

설명구분

'년.월.일 시간:분:초' 의 형식으로 출력된다.시간

로그 레벨이 매핑되는 숫자로 출력된다. 모두 SEVERE로 0으로 표시된다.레벨

JEUS의 빌드 버전을 표시한다.버전

Logging하는 프로세스(노드 또는 컨테이너 이름)와 스레드 번호로 표현되

며, 이 둘은 하이픈('-')으로 구분된다. 스레드 정보가 같은 로그는 같은 스레

드에서 Logging한 메시지이다.

Logging되는 스레드 정보

Logging하려는 메시지가 표준 출력인 경우 STDOUT, Exception과 같은 표

준 에러인 경우 STDERR, 알 수 없는 경우는 UNKNOWN으로 표시된다.

STDOUT/STDERR

System.out이나 System.err를 통해 출력할 메시지이다.메시지

11.3.4. 동적으로 Logging 레벨 설정

jeusadmin이나 WebAdmin을 통해서 런타임(runtime)에 동적으로 설정을 변경할 수 있다.

● jeusadmin

loglevel 명령어를 사용하여 Logging 설정을 동적으로 변경할 수 있다.

johan>loglevel -con johan_container1 jeus.ejb FINE

위의 예제는 loglevel 명령어를 사용하여 johan_container1에 있는 jeus.ejb의 로거 레벨을 FINE으로 변

경하는 것을 보여주고 있다.

참고

이 명령어에 대한 자세한 내용은 "JEUS Reference Book"의 jeusadmin commands를 참고한다.

● WebAdmin

로그 설정 페이지에서 Logging 설정을 동적으로 변경할 수 있다.

11.3.5. 프로퍼티 설정

● 시스템 프로퍼티 설정


XML 설정이 불가능한 경우에 시스템 프로퍼티로 설정할 수 있다.

– Standalone 클라이언트에서 로거 설정을 할 경우

– XML에서 설정이 불가능한 세부 로거 설정을 할 경우(예: -Djeus.transaction.log.level = FINE)

● Logging 프로퍼티 파일

JEUS나 Java Logging 프로퍼티 파일에 Logging 설정을 할 수 있다.

– JEUS Logging 프로퍼티(jeuslogging.properties) 파일

-Djeus.logging.propertyfile로 프로퍼티 파일 경로를 지정할 수 있다.

기본 경로는 "JEUS_HOME\config\jeuslogging.properties"이다.

– Java Logging 프로퍼티(logging.properties) 파일

-Djava.util.logging.config.file로 프로퍼티 파일 경로를 지정할 수 있다.

기본 경로는 "JEUS_HOME\bin\logging.properties"이다.

레벨 설정 우선 순위

JEUS 툴을 이용한 동적 설정을 제외한 나머지 설정들의 레벨 설정 우선순위는 다음과 같다.

1. 시스템 프로퍼티

2. JEUS Logging 프로퍼티(jeuslogging.properties) 파일

3. Java Logging 프로퍼티(logging.properties) 파일

4. XML(JEUSMain.xml) Logging 설정

참고

핸들러에 설정한 로그 레벨은 위에서 언급한 설정 우선 순위를 치환(Override)하는 것은 아니다. 하

지만 최종적으로 핸들러를 통해서 로그가 출력되기 때문에 가장 높은 순위에 있다고 할 수 있다. 참

고로 핸들러의 기본 로그 레벨은 FINEST이다.


Appendix A. JEUS에서 사용하는 Port

본 부록에서는 JEUS에서 사용하는 Port를 정리한다. 방화벽을 설정하는 경우 참고한다.

A.1. 서버 Port● BASEPORT

JEUS Manager가 JNDI 서비스 및 운영을 위해 필요한 기본 서비스 Port설명

9736Base Port

● COS Naming Server Port

COS Naming 서비스를 위해 사용하는 Port설명

BASEPORT + 4 (e.g. 9740)Base Port

● WebAdmin Port

WebAdmin 서비스를 위해 사용하는 Port설명

BASEPORT + 8 (e.g. 9744)Base Port

● 엔진 컨테이너 BASEPORT

엔진 컨테이너별 기본 서비스 Port설명

BASEPORT + 15 + (엔진 컨테이너 ID * 10)Base Port

● ORB Port

IIOP Port설명

엔진 컨테이너 BASEPORT + 1Base Port

● ORB SSL Port

IIOP SSL Port설명


Appendix A. JEUS에서 사용하는 Port 189

● ORB SSL Mutual Authorization Port

IIOP 상호인증 Port설명


● HTTP Port

8088Base Port

● EJB RMI Port

EJB를 접근하기 위한 RMI Port. use-baseport 설정이 있는 경우 Container BASEPORT

를 사용

설명

엔진 컨테이너 BASEPORT + 7 or 엔진 컨테이너 BASEPORTBase Port

● JMS 엔진 Port

JMS 서비스 Port. oneport 설정시 Container BASEPORT를 사용설명

9741 or 엔진 컨테이너 BASEPORTBase Port


Appendix B. JDBC Data Source 구성 예제

본 부록에서는 주요 JDBC 드라이버들에 대한 Connection Pool 설정 예제를 제공한다.

B.1. 개요설정 가능한 JDBC Data Source는 다음과 같다.

● Oracle Thin

● Oracle OCI

● DB2 Type 4(JCC)

● DB2 Type 2(JCC)

● Sybase jConnect 5.x, 6.x

● MSSQL 2005 Type 4

● Informix Type 4

● Tibero Type 4

● MySQL 5.x Type 4

본 부록의 XML 예제들은 JEUSMain.xml에 작성하면 된다. 각 예제에서 중요한 값들은 bold체로 표현한다.

B.2. Oracle Thin(Type 4) 구성 예제

B.2.1. Oracle Thin Connection Pool DataSource

[예 B.1] <<JEUSMain.xml>>

<jeus-system>

. . .

<resource>

<data-source>

<database>





Appendix B. JDBC Data Source 구성 예제 191


<data-source-type>

ConnectionPoolDataSource

</data-source-type>

<database-name>orcl</database-name>



<user>scott</user>


<property>



<value>thin</value>

</property>

<connection-pool>

<pooling>

<min>2</min>

<max>4</max>


</pooling>





</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>

B.2.2. Oracle Thin XA Data Source


<jeus-system>

. . .

<resource>

<data-source>

<database>


<export-name>xaoralce</export-name>


oracle.jdbc.xa.client.OracleXADataSource



<data-source-type>XADataSource</data-source-type>

<database-name>ora9</database-name>



<user>scott</user>


<property>



<value>thin</value>

</property>

<connection-pool>

<pooling>

<min>2</min>

<max>10</max>


</pooling>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>

B.2.3. java.util.Properties 설정 예제 with Oracle ASO

Oracle ASO 설정 예제를 이용해서 java.util.Properties 설정 방법에 대해 설명한다.

<property>를 사용하고, 기본 형식은 <type>은 java.util.Properties, <value>는 [프로퍼티 이름 1]=[값 1],

[프로퍼티 이름 2]=[값 2]와 같은 형식으로 입력한다.


<jeus-system>

. . .

<resource>

<data-source>

<database>


<export-name>xaoralce</export-name>




<data-source-type>



</data-source-type>

<database-name>ora9</database-name>



<user>scott</user>


<property>



<value>thin</value>

</property>

<property>

<name>ConnectionProperties</name>

<type>java.util.Properties</type>

<value>

oracle.net.encryption_client=xxxx,

oracle.net.encryption_types_client=(3DES168,3DES112),

oracle.net.crypto_checksum_client=xxxx,

oracle.net.crypto_checksum_types_client=(MD5)

</value>

</property>

<connection-pool>

<pooling>

<min>2</min>

<max>10</max>


</pooling>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>

B.3. Oracle OCI (Type 2) 구성 예제

B.3.1. Oracle OCI Connection Pool DataSource

Oracle OCI 드라이버를 사용하기 위해서는 선행 작업이 필요한데, JEUS 실행 스크립트

(JEUS_HOME/bin/jeus 또는 jeus.bat)에서 -Djava.library.path로 Oracle OCI 드라이버의 네이티브 라이브

러리 경로를 설정해야 한다.



<jeus-system>

. . .

<resource>

<data-source>

<database>


<export-name>oracle_oci_pool1</export-name>





<user>scott</user>


<property>



<value>oci</value>

</property>

<property>

<name>TNSEntryName</name>


<value>ORCL</value>

</property>

<connection-pool>

<pooling>

<min>10</min>

<max>20</max>


</pooling>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


B.4. DB2 구성 예제

B.4.1. DB2 Type 4(JCC) Connection Pool DataSource


<jeus-system>

. . .

<resource>

<data-source>

<database>

<vendor>db2</vendor>

<export-name>db2_pool1</export-name>


com.ibm.db2.jcc.DB2ConnectionPoolDataSource



<database-name>TEST1</database-name>



<user>db2inst1</user>

<password>db2inst1</password>

<property>



<value>4</value>

</property>

<connection-pool>

<pooling>

<min>10</min>

<max>20</max>


</pooling>

<check-query>

SELECT COUNT(*) FROM SYSIBM.SYSTABLES

</check-query>


</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


B.4.2. DB2 Type 4(JCC) XA DataSource


<jeus-system>

. . .

<resource>

<data-source>

<database>


<export-name>db2_xa1</export-name>


com.ibm.db2.jcc.DB2XADataSource








<property>



<value>4</value>

</property>

<connection-pool>

<pooling>

<min>10</min>

<max>20</max>


</pooling>

<check-query>

SELECT COUNT(*) FROM SYSIBM.SYSTABLES

</check-query>

<keep-connection-handle-open>true</keep-connection-handle-open>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


B.4.3. DB2 Type 2(JCC) XA DataSource

DB2 Type 2 드라이버를 사용하기 위해서는 DB2 클라이언트를 설치하여 DB Alias를 설정한 뒤, JEUS 실

행 스크립트(JEUS_HOME/bin/jeus 또는 jeus.bat)에서 -Djava.library.path 또는 시스템의 라이브러리 경

로에 DB2 클라이언트의 네이티브 라이브러리 경로를 설정해야 한다. 다음의 예제에서 <database-name>

이 DB Alias가 되고 DB2 서버 주소와 포트 번호는 입력할 필요가 없다.


<jeus-system>

. . .

<resource>

<data-source>

<database>


<export-name>db2_xa1</export-name>


com.ibm.db2.jcc.DB2XADataSource






<connection-pool>

<pooling>

<min>10</min>

<max>20</max>


</pooling>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


B.5. Sybase 구성 예제

B.5.1. Sybase jConnect 5.x Connection Pool DataSource


<jeus-system>

. . .

<resource>

<data-source>

<database>

<vendor>sybase</vendor>

<export-name>sybasedatasource</export-name>


com.sybase.jdbc2.jdbc.SybConnectionPoolDataSource


<data-source-type>


</data-source-type>

<database-name>testdb</database-name>



<user>sa</user>

<password>sybase</password>

<property>

<name>networkProtocol</name>


<value>Tds</value>

</property>

<connection-pool>

<pooling>

<min>10</min>

<max>50</max>

<step>5</step>


</pooling>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


B.5.2. Sybase jConnect 6.x XA DataSource


<jeus-system>

. . .

<resource>

<data-source>

<database>

<vendor>sybase</vendor>

<export-name>XAsybase</export-name>


com.sybase.jdbc3.jdbc.SybXADataSource


<data-source-type>

XADataSource

</data-source-type>

<database-name>testdb</database-name>

<property>

<name>networkProtocol</name>


<value>Tds</value>

</property>



<user>sa</user>

<password>sybase</password>

<connection-pool>

<pooling>

<min>10</min>

<max>50</max>

<step>5</step>


</pooling>





</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


B.6. MSSQL 구성 예제

B.6.1. MSSQL 2005 Connection Pool DataSource


<jeus-system>

. . .

<resource>

<data-source>

<database>

<vendor>mssql</vendor>

<export-name>mssqldatasource</export-name>


com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource


<data-source-type>


</data-source-type>

<database-name>jeusdb1</database-name>



<user>jeusdb1</user>

<password>jeusdb1</password>

<connection-pool>

<pooling>

<min>5</min>

<max>10</max>


</pooling>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>

참고

ODBC 설정은 JDBC보다 먼저 설정되어야 한다.


B.7. Informix 구성 예제

B.7.1. Informix Connection Pool Datasource


<jeus-system>

. . .

<resource>

<data-source>

<database>

<vendor>informix</vendor>

<export-name>informix_pool1</export-name>


com.informix.jdbcx.IfxConnectionPoolDataSource



<database-name>skynps</database-name>


<server-name>ids93fc</server-name>

<user>informix</user>

<password>informix</password>

<property>

<name>IfxIFXHOST</name>


<value>192.168.1.43</value>

</property>

<connection-pool>

<pooling>

<min>10</min>

<max>20</max>


</pooling>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


B.8. Tibero 구성 예제

B.8.1. Tibero Connection Pool Datasource


<jeus-system>

. . .

<resource>

<data-source>

<database>

<vendor>tibero</vendor>

<export-name>tibero_pool1</export-name>


com.tmax.tibero.jdbc.ext.TbConnectionPoolDataSource



<database-name>tibero</database-name>



<user>jeusdb1</user>

<password>jeusdb1</password>

<property>



<value>thin</value>

</property>

<connection-pool>

<pooling>

<min>10</min>

<max>20</max>


</pooling>

</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


B.9. MySQL 5.x 구성 예제

B.9.1. MySQL Connector/J Connection Pool Datasource


<jeus-system>

. . .

<resource>

<data-source>

<database>

<vendor>mysql</vendor>

<export-name>mysql_pool1</export-name>


com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource



<database-name>test</database-name>



<user>tester</user>

<password>tester</password>

<connection-pool>

<pooling>

<min>2</min>

<max>10</max>

<step>1</step>


</pooling>




<check-query>select 1</check-query>


</connection-pool>

</database>

. . .

</data-source>

. . .

</resource>

</jeus-system>


Appendix C. standard.property

Jeus-ejb-dd.xml, jeus-web-dd.xml없이 JavaEE 애플리케이션을 Deploy할 때, 기본 설정으로 사용되는 항

목값을 정의한다. 이 항목은 jeus-ejb-dd.xml과 jeus-web-dd.xml의 항목을 하나로 정리한 것이다. 기본적

으로 JEUS_HOME\config\<node name>에 위치한다.

참고

각 항목의 자세한 내용은 "JEUS EJB 안내서"나 "JEUS Web Container 안내서"를 참고한다.

C.1. 프로퍼티 레퍼런스

[표 C.1] 프로퍼티 레퍼런스

기본값설명프로퍼티

N/ADB 벤더명vendor

N/ACMP에서 사용할 데이터소스datasource-name

falseCMP의 Table 생성 여부creating-table

falseCMP의 Table 삭제 여부deleting-table

EXCLUSIVE_ACCESSEntity Bean의 엔진 타입engine-type

ReadLockingCMP의 서브 엔진 타입subengine-type

10ResultSet으로 한 번에 가져올 수 있는 레코드의 수fetch-size

falseJEUS의 Instance QL 사용 여부enable-instant-ql

trueLocal Invoke Optimize 사용 여부local-optimize

fatal로그 레벨logging-level

0RMI Listener Portexport-port

falseCOS Naming 사용 여부export-iiop

false해당 컨테이너의 JNDI에만 객체를 bindsingle-vm-only

20최소 스레드 개수thread-pool-min

100최대 스레드 개수thread-pool-max

20스레드 증가 개수thread-pool-step

3600000스레드 개수 조정 시간 간격thread-pool-resize

0EJB bean의 최소 개수bean-pool-min

100EJB bean의 최대 개수bean-pool-max

Appendix C. standard.property 205

기본값설명프로퍼티

3600000EJB bean 개수 조정 시간 간격bean-pool-resize

10000EJB bean 인스턴스의 capacitycapacity

-1EJB가 Passivate되는 시간passivation-timeout

-1EJB의 인스턴스가 완전히 사라지는 시간disconnect-timeout

0EJB Connection Pool의 최소 개수connect-pool-min

100EJB Connection Pool의 최대 개수connect-pool-max

3600000EJB 커넥션 개수의 조정 시간 간격connect-pool-resize

N/AJMS 커넥션의 export namejms-connection

N/AURL 리소스의 export namemail-connection

N/AURL 리소스의 export nameurl-connection

falseEntity Bean을 미리 초기화할지 여부init-caching


용어해설

임시 커넥션

Connection Pool이 꽉 찼을 때, 만들어져서 사용 후 폐기되는 커넥션이다.

클러스터링

서로 간에 연결된 컴포넌트의 그룹이다. 시스템을 더 안정적이고 효율적으로 만들 때 사용된다.

base port

다른 포트 번호를 계산하는 데 기본이 된다. 그리고 클라이언트가 JEUS Manager로 접속하기 위해서도 설정

한다. (기본값 : 9736)

container

런타임 애플리케이션 환경을 제공하는 실제 소프트웨어 구조이다.

EIS

기존의 Enterprise Information System이다.

engine

EJB와 Servlet과 같은 비즈니스 애플리케이션 실행을 위한 infrastructure를 제공한다(엔터프라이즈 애플리케

이션에 서비스를 제공한다). 엔진은 Java EE 스펙에 따라 보통 “container”라 불린다.

JEUS에서 지원하는 엔진 타입은 EJB, Servlet, JMS, WS(Web server implementation)이다.

engine container

JEUS에서만 사용하는 개념으로, 여러 엔진을 관리하는 단위이다. Engine 컨테이너는 JEUS Manager와는 다

른 별개의 JVM 에서 동작한다. 단 ‘default’ Engine Container는 JEUS Manager와 동일한 JVM에서 동작한다.

JavaEE

Java Platform, Enterprise Edition. Sun Microsystems에서 제정한 스펙들을 일컫는다. 이 스펙은 엔터프라이

즈 애플리케이션을 Java 플랫폼으로 구현하는 것에 대해 정의하고 있다. JEUS는 JavaEE 5 스펙을 구현하고

있다.

JEUS

Java Enterprise User Solution의 약자이다. 본 안내서에서 소개하는 JEUS 버전 6는 JavaEE 5 호환 WAS이다.

JVM

Java Virtual Machine의 약자이다.

load balancing

클러스터링에서 작업이 한쪽으로 치우치지 않도록 하는 기술이다.

node

각 JEUS 노드는 JEUS Manager에 의해 관리된다. 하나의 머신에서 작동하는 JEUS의 실제 인스턴스이다.

용어해설 207

RA

Resource Adapter의 약어이다.

RM

Resource Manager의 약어이다.

session

동일한 클라이언트에 의해 제한된 시간 내에 수행된 관련 있는 동작들의 집합이다.

TM

Transaction Manager의 약어이다.

TO (to)

TimeOut의 약어이다.

WAS

웹 애플리케이션 서버(Web Application Server)의 약자로, 복잡한 웹 애플리케이션을 실행하고 관리하는 미들

웨어이다.

WebtoB

TmaxSoft의 고성능 웹 서버(HTTP Server)이다.


색인

Symbols<application>, 19

<check-query-timeout>, 98

<check-query>, 98

<database><connection-pool>

<check-query-class>, 96

<check-query-period>, 96

<check-query-retrial-count>, 96

<check-query>, 95

<connection-trace>, 96

<dba-timeout>, 95

<delegation-datasource>, 94

<delegation-dba>, 95

<destroy-policy-on-check-query>, 96

<init-sql>, 97

<keep-connection-handle-open>, 97

<max-use-count>, 95

<non-validation-interval>, 95

<pooling>, 94

<stmt-caching-size>, 96

<stmt-fetch-size>, 96

<use-sql-trace>, 97

<wait-free-connection>, 94, 95

<engine-command>

< type>, 31

<name>, 31

<system-logging>, 31

<engine-container>

<application-path>, 25

<base-port>, 24

<command-option>, 24

<enable-interop>, 25

<engine-command>, 29

<id>, 24

<jmx-manager>, 29

<name>, 24

<scheduler>, 29

<sequential-start>, 24

<start-on-boot>, 24

<use-MEJB>, 25

<user-class-path >, 25

<user-logging>, 29

<engine-container><res-ref><jndi-info>

<export-name>, 27

<ref-name>, 27

<file-handler>

<append>, 186

<enable-rotation>, 185

<rotation-count>, 185

<Rotation-dir>, 185

<valid-day>, 186

<valid-hour>, 186

<valid-size>, 186

<groups>, 60

<description>, 61

<name>, 61

<subgroup>, 61

<handler><console-handler>

<encoding>, 182

<filter-class>, 182

<level>, 182

<name>, 181

<handler><file-handler>

<append>, 182

<buffer-size>, 182

<enable-rotation>, 182

<filter-class>, 182

<rotation-count>, 182

<rotation-dir>, 182

<valid-day>, 182

<valid-hour>, 182

<valid-size>, 182

<handler><smtp-handler>

<append>, 183

<bcc-address>, 183

<cc-address>, 183

<from-address>, 183

<send-for-all-messages>, 183

<to-address>, 183

색인 209

<handler><socket-handler>

<address>, 183

<port>, 183

<handler><user-handler>

<formatter-class>, 184

<formatter-property>, 184

<handler-class>, 183

<handler-property>, 183

<invocation-manager-action>, 26

<lifecycle-invocation>

<class-name >, 27

<invocation>, 27

<log-stdout-to-raw-format>, 186

<naming-server>, 18

<naming-server><local>

<name>, 68

<naming-server><server>

<backlog-size>, 68

<export-cos-naming>, 68

<pooling>, 68

<use-nio>, 68

<node>, 18

<backup-node>, 21

<class-ftp>, 21

<enable-jnlp>, 22

<enable-webadmin>, 21

<engine-container>, 22

<jmx-manager>, 22

<listener>, 21

<name>, 20

<scheduler>, 22

<sequential-start>, 21

<session-router-config>, 22

<session-server>, 22

<system-logging>, 22

<webadmin-config>, 21

<non-validation-interval>, 98

<resource>, 19, 78

<external-resource>, 80

<jaxr-source>, 81

<mail-source>, 79

<url-source>, 79

<resource> <data-source> <cluster-ds>

<data-source-id>, 103

<data-source-selector>, 103

<data-source-target>, 103

<data-source>, 103

<export-name>, 103

<is-pre-conn>, 103

<load-balance>, 103

<use-failback>, 103

<resource><data-source><database>

<action-on-connection-leak>, 91

<auto-commit>, 90

<connection-pool>, 90

<data-source-class-name>, 90

<data-source-id>, 89

<data-source-name>, 90

<data-source-target>, 90

<data-source-type>, 90

<database-name>, 90

<description>, 90

<driver-type>, 90

<export-name>, 89

<login-timeout>, 91

<network-protocol>, 90

<password>, 90

<port-number>, 90

<property>, 90

<server-name>, 90

<service-name>, 90

<stmt-query-timeout>, 90

<user>, 90

<vendor>, 89

<security-manager>, 18


<backup-trigger>, 159

<check-level>, 159

<check-to>, 159

<connect-timeout>, 159

<default-file-db>, 160

<read-timeout>, 159

<session-router>, 160

<thread-pool>, 159

<session-server>

<backup-trigger>, 145


<check-level>, 145

<check-to>, 145

<connect-timeout>, 144

<file-db-name>, 145

<file-db-path>, 145

<min-hole>, 145

<packing-rate>, 145

<passivation-to>, 144

<read-timeout>, 144

<recovery-mode>, 145

<removal-to>, 145

<resolution>, 144

<thread-pool>, 144

<type>, 144

<system-logging>

<filter-class>, 181

<handler>, 181

<level>, 181

<name>, 181

<use-parent-handlers>, 181

<tm-config>

<active-timeout>, 121

<commit-timeout>, 121

<prepare-timeout>, 121

<prepared-timeout>, 121

<recovery-timeout>, 121

<tm-config><pooling>

<max>, 120

<min>, 120

<period>, 120

<users>, 60

<description>, 60

<group>, 60

<name>, 60

<password>, 60

AActive Timeout, 124

AllConnections, 99

allenglist, 38

BBackup Manager, 141

Backup Session Server, 141

Backup Store, 153

base port, 7

Basic Data Source, 84

beacon receiver, 47

Bean 관리 트랜잭션, 130

Binding Option

CACHE_BINDINGS, 71

LOCAL_BINDINGS, 71

REPLICATE_BINDINGS, 70

Binding Option 설정, 69

CCached session(Session Cache Memory), 141

Check-query 클래스, 99

checkConnection(), 99

setQueryString(), 99

setQueryTimeout(), 99

Class FTP 서비스, 5

Class Loader의 구조, 14

Client-side JNSLocal, 65

Client-side JNSLocal 설정, 69

Commit Timeout, 125

conlist, 37

Connection Pool 데이터 소스, 85

Container-Managed 트랜잭션, 116

Controlling DB Connection Pools, 107

Custom DB Properties, 92

DData source, 77

Data Source, 5

DataSource, 84

EEJB class loader, 15

EJB module class loader, 15

EJB 엔진, 8

EJB 클러스터링, 45

EJBMain.xml, 30

색인 211

External Source, 6

FFailedConnectionOnly, 98

HHttp 세션 클러스터링 서비스, 5, 8

IIBM MQ, 78

InitialContext, 64, 69, 72

Invocation Manager, 10

Isolated Class Loader, 14

JJAXR, 78

JAXR Source, 6

JCA RM, 118

JDBC RM, 118

jeus, 19, 33

JEUS Manager, 1, 3, 17

JEUS Manager 기동, 33

JEUS Manager 종료, 34

JEUS root class loader, 15

jeus.ssl.keypass, 58

jeus.ssl.keystore, 58

jeus.ssl.trustpass, 58

jeus.ssl.truststore, 58

jeus.tm.noLogging, 137

jeus.tm.resizingPeriod, 124

jeus.tm.tmMax, 124

jeus.tm.tmMin, 124

jeusadmin, 33, 34, 35, 37, 38, 53

JEUSMain.xml, 17, 22, 46, 47

JMS Engine, 8

JMS RM, 118

JMSMain.xml, 30

JMX 관리자, 22

JNDI, 63

JNDI Naming Server, 63

JNDI Naming 서버, 4

JNDI 서비스, 2, 3, 4

JNDI 클러스터링, 45, 65

JNDI 트리, 63

JNLP Server, 22

JNSContext.CONNECT_TIMEOUT, 69

JNSContext.CONNECTION_DURATION, 69

JNSContext.RESOLUTION, 69

JNSLocal, 63, 64

JNSServer, 63, 64

LLogging, 22

Logging 서비스, 2, 4

MMail resource, 77

Mail Source, 6

Mangement 서비스, 4, 9

MessageHandler, 154

Monitoring DB Connection Pools, 108

PPrepare Timeout, 125

Prepared Timeout, 125

Programming with JEUS JDBC, 112

RRecovery LogFile, 137

Recovery Timeout, 125

SSCRemoteContainer, 153

Security 도메인 클러스터링, 45

security.key, 57

Server-side JNSLocal, 65

Server-side JNSLocal 설정, 68

Servlet 엔진, 8

Session Manager, 140, 152

Session Manager의 메모리 관리, 142

Session Storage, 141

Shared Class Loader, 15

Sonic MQ, 78


TThread interrupt, 41

Tmax (WebT) RM, 118

UURL resource, 77

URL Source, 6

User-Managed 트랜잭션, 116

WWeb class loader, 15

Web context class loader, 15

Web Server 엔진, 8

WEBMain.xml, 30

XXA 데이터 소스, 85

ㄱ

가상 노드, 2

가상 노드 설정, 22

글로벌 트랜잭션, 116

ㄴ

노드, 1, 2

노드 기동, 35

노드 모니터링, 36

노드 제어, 35

노드 종료, 35

노드 클러스터링, 45

노드 클러스터링 설정, 23

ㄷ

데이터 소스 사용자 이름 및 패스워드의 관리, 91

ㄹ

로그 파일 Rotation 기능, 184

로그 포맷, 172

로컬 XA 데이터 소스, 85

로컬 트랜잭션, 116, 126

리소스 매니저, 118

ㅂ

백업 노드, 50

보안 서비스, 2, 4

보안(Security) 서비스, 4

분산 세션 서버, 22, 139, 151

분산 세션 서버 기본 설정, 158

분산 세션 서버 세션 클러스터링, 155

분산 세션 서버의 구조, 151

분산 세션 서버의 동작 방식, 154

분산 세션 서버의 백업 서버 선택 방식, 155

분산 세션 서버의 설정, 157

ㅅ

서버 트랜잭션 매니저, 117

세션 서버, 22, 142

세션 클러스터링, 45

스케줄러, 22

스케쥴러 서비스, 5

ㅇ

엔진, 8

엔진 모니터링, 38

엔진 제어, 38

엔진 컨테이너, 2, 7, 22

엔진 컨테이너 모니터링, 37

엔진 컨테이너 제어, 37

외부 리소스(External Resources), 5

웹 서버 클러스터링, 45

웹 컨테이너의 설정, 147

ㅈ

정적 클러스터링 구성, 48

중앙 세션 서버, 139

중앙 세션 서버 기본 설정, 143

중앙 세션 서버에서 노드 클러스터링과 세션 클러스터

링 설정, 146

중앙 세션 서버의 구조, 140

중앙 세션 서버의 세션 클러스터링, 141

ㅋ

컨테이너 관리 트랜잭션, 133

색인 213

콘솔 툴, 4

클라이언트 관리 트랜잭션, 128

클라이언트 트랜잭션 매니저, 117

클라이언트와 중앙 세션 서버의 관계, 141

클러스터링, 45, 46

ㅎ

핸들러

SMTP 핸들러, 183

사용자 핸들러, 183

소켓 핸들러, 183

콘솔 핸들러, 181

파일 핸들러, 182

Documents

JEUS Server 안내서 - TmaxSoft · 2019-04-09 · 3.2.2. Thread 제어..... 41 제4장 JEUS 클러스터링 ... 제8장 DB Connection Pool