Scent of Life

KSUG(Korea Spring User Group)에 게시된 "VO vs DTO"와 관련한 글타래를 보던 중 한가지 떠오른 것이 있었다.

2004년 경에 ASP.Net 환경의 웹 어플리케이션 개발을 위해 C# 기반의 "AdvDotNet"이란 프레임워크를 개발했었다. 이 프레임워크의 기능 중 하나로, 페이지의 Form으로부터 데이터를 전송받거나 또는 Database에서 조회한 데이터를 페이지의 DataGrid에 바인딩하는 일련의 작업 효율을 높이기 위해 Attribute와 Reflection을 사용하여 어느정도 자동화된 기반 구조를 구현하여 지원했다. BaseEntity라는 클래스와 이들의 Collection을 처리하는 일련의 코드들이었는데, 닷넷 개발자들에게 이러한 구조를 설명하기 위해 정리한 내용 중 "DataTransferObject"라는 타이틀의 문서가 있었다.

...
이러한 n-tier 환경에서 각 계층 간에 데이타를 교환하기 위해서는 데이터 전송용 객체(Data Transfer Object, 이하 DTO)를 사용하기 마련인데, 사실 DTO는 어느 정도의 규모가 되는 시스템이라면 개발자들이 부담을 가질 정도로 수가 많아지고 코딩량이 증가하고 번거로워지기 일수이다.
...
DTO는 VO(Value Object)라는 이름으로 불려지기도 한다. 엄밀한 의미로는 DTO와 VO는 차이가 있지만 일반적으로 동일한 개념으로 받아들인다.  DTO와 달리 VO는 일반적으로 read only 속성을 갖는다.
...

문서에서 나는 DTO를 위와 같이 설명했다(Reflection을 사용함으로써 발생하는 퍼포먼스의 저하는 향상된 코딩 효율과 개발 용이성으로 상쇄될 수 있는 부분임을 강조하기 위해 DTO를 사용할 때 코딩의 번거로움을 먼저 화두를 꺼내고 있다).

내가 프레임워크에 대한 개념을 정립하는데는 2000년 당시에 보았던 javaservice.net의 JDF 관련 문서들이 큰 도움이 되었었는데, 이때에는 현재의 DTO를 "Entity Class"라고 표현했던 기억이 난다. 후에는 상황에 따라 DTO, VO, Model, Entity, JavaBean 등 다양하게 표현하고 또 들을 수 있었다. 여기서 "Model"이란 용어도 다소 헷갈리는 부분인데, 주로 Domain Model로서 DTO를 표현할 때에는 "로직을 갖고 있지 않은 객체로 속성(member)과 그 속성에 접근하기 위한 getter/setter 메서드를 갖는 JavaBean 클래스"를 나타내는 것이었지만, 사실 MVC 패턴의 관점에서 보면 Model은 비즈니스 구현부도 포함하기 때문이다.

• http://martinfowler.com/eaaCatalog/dataTransferObject.html
• http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
• http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
• http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

개발자들의 주변에는 항상 신기술과 함께 IT, 개발 관련 용어들이 범람하고 있다. 사람인지라 모든 것을 이해하기는 불가능하기 때문에 간혹 용어의 의미가 혼동되는 경우 또한 적지 않은데, 오용하지 않기 위해서라도 그때그때 제대로 된 개념을 정립할 필요가 있을 것 같다.

얘기 나온 김에 예전에 세미나 자료로 작성했던 내용인데, Framework와 관련 용어들 중 의미와 경계가 불명확한 개념들에 대해 정리했던 부분을 옮겨본다. 미리 얘기하지만 이것들이 정답은 아니다. ^^

Framework와 관련 용어

혼동되는 개념들과 비교하여 Framework를 정의해본다. 프레임워크와 관련된 주요 개념들이다. 이들은 프레임워크로 실현되기도 하고, 상호 포함관계를 갖기도 하고, 이용관계를 갖기도 한다.

1. Framework vs Library

어플리케이션은 여러 클래스들이 상호작용하면서 그 기능을 수행하는데, 특정 기능을 수행하는 클래스들을 클래스 라이브러리(Class Library) 혹은 툴킷(Toolkit)이라고 한다. 클래스 라이브러리는 범용적으로 사용할 수 있는 기능을 제공하는 재사용할만한 연관된 클래스들의 묶음이다. 클래스 라이브러리와 프레임워크간의 가장 큰 차이는 제어 권한의 위치에 있다.

• 라이브러리는 사용자 코드에서 활용하는 것이다.
• 프레임워크는 사용자 코드가 준수해야하는 것이다.

(※ 사용자 코드: 개발자가 직접 비즈니스 로직을 구현한 코드)

2. Framework vs Component

컴포넌트는 표준으로 정의된 컨테이너 규약 하에서 독립적으로 사용할 수 있는 소프트웨어 모듈이다. 컴포넌트의 기능은 인터페이스로 정의되며 그 내부 구현은 감추어져 있다. 프레임워크가 어플리케이션 기반 구조에 더 초점을 맞춘 개념인 반면, 컴포넌트는 컨테이너라고 하는 기반 구조에서 작동하는 모듈에 초점을 맞춘 개념이라는 점에서 차이가 있다.

컴포넌트와 프레임워크를 혼동시키는 점들

• 프레임워크와 컴포넌트의 컨테이너는 애플리케이션을 이루는 기반 구조라는 점에서 매우 유사하다.
• 프레임워크에 등록하는 사용자정의 확장 모듈은 같은 종류의 프레임워크에서 재사용 가능하기 때문에 컴포넌트의 경우와 그 형태가 유사하다. 이런 관계 때문에 컴포넌트와 프레임워크를 혼용하게 되거나 분류가 어려워진다.
• 컴포넌트는 컨테이너-컴포넌트간의 관계 구조나 컨테이너, 컴포넌트 각각의 내부 구조를 구현하는 데 있어 프레임워크를 사용하기도 한다. 프레임워크는 핫 스팟(Hot Spot)과 콜드 스팟(Cold Spot) 구현 단위나 핫 스팟 인터페이스 설정에 있어 컴포넌트의 개념을 사용하기도 한다.

이런 관계로 일반적으로 프레임워크가 오래 사용되어서 기반 구조가 안정화되고 그 프레임워크를 확장해서 구현한 모듈이 많아지게 되면 그 자체가 바로 컴포넌트와 컨테이너가 된다.

3. Framework vs Design Pattern

디자인 패턴과 프레임워크는 이미 성공한 솔루션에서 유래했다는 점과 다른 유사한 사례에서 재사용될 수 있다는 점에서 공통점을 갖는다.

디자인 패턴과 프레임워크의 공통적 특징

• 어플리케이션의 구조와 디자인을 결정한다.
• 반복적으로 발견되는 문제를 해결하기 위한 특화된 솔루션이다.

4. Framework와 Architecture

프레임워크와 아키텍처는 한마디로 밀접한 관계이다. 최종적으로 완성되는 아키텍처는 사용하는 프레임워크의 종류와 그 사용 전략이 결합되어 결정된다.

아키텍처에 따라 프레임워크의 선택이 제약될 수 있다.

• 리치 클라이언트(Rich Client) 아키텍처라면 AJAX 프레임워크 또는 X-Internet 도입을 고려
• 3계층(N-Tier) 기반의 분산형 아키텍처라면 C/S를 위한 프레임워크는 사용할 수 없다.

선택된 프레임워크에 따라 아키텍처가 달라질 수 있다.

• MVC 기반의 웹 프레임워크를 사용하려고 한다면 그에 맞게 Model2 아키텍처를 사용해야 한다.
• 프레임워크가 지원하는 패턴에 따라 아키텍처 관점에서 매우 제한적인 프레임워크가 있는 반면에 다양한 아키텍처를 지원하는 유연한 프레임워크도 있다.

Structure? Architecture? Framework?

• 스트럭처는 트리(Tree)와 같은 계층적(Hierarchical)인 기반 구조를 말한다.
• 프레임워크는 다소 수평적인 의미를 갖는 하부 구조(Infra Structure)를 나타낸다.
• 아키텍처는 더 포괄적인 개념으로 스트럭처와 프레임워크 모두를 포함하는 체계적인 기반 구조를 의미한다.

따라서 프레임워크와 아키텍처는 다음과 같이 표현할 수 있다.

현재 웹어플리케이션을 개발하기 위해 한창 프로젝트를 진행하고 있거나, 기존 웹사이트를 유지보수 하고 있는 개발자들에게 Internet Explorer 8(이하 IE8)의 등장은 부담이 아닐 수 없다.

현재 수행중인 프로젝트의 경우에도 초기에 웹 표준 준수를 목표 잡고 Internet Explorer, Firefox 등 다양한 브라우저와 버전들에서 테스트를 병행하여 개발을 진행해왔다. 그럼에도 불구하고 새롭게 등장한 IE8 버전에서 테스트한 결과, 페이지 레이아웃이 다소 깨지거나 동작에 문제가 발생하는 부분들이 발생하였다. 프로젝트 시작하던 올 초 IE8 출시를 예고되던 시점부터 우려하던 내용이 현실이 되고말았다.

지난주 IE8에서 사이트의 레이아웃이 깨지는 것이 크게 이슈화되었고, 이를 처리하기 위한 방법을 고민하던 중 다행히 간단한 코드를 통하여 전체 페이지의 레이아웃을 바로잡을 수 있었다.

다음은 meta.jspf 의 일부인데, 내가 한 작업이라고는 첫번째 메타(META) 태그를 추가한 것이 전부이다.

<%@ page pageEncoding="utf-8" %> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/> <meta http-equiv="Cache-Control" content="no-store"/> <meta http-equiv="Pragma" content="no-cache"/> <meta http-equiv="Expires" content="0"/> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

아래 IE8에서 테스트한 화면을 보면 Poll 설문조사 부분이 완전히 어긋나 있다.

DTD가 없는 웹 사이트 대응 방법

DTD가 있는 웹 사이트 대응 방법

DTD가 있고 IE5에 최적화 된 페이지 대응 방법

<meta http-equiv="X-UA-Compatible" content="IE=5"/>

DTD가 있고 IE6에 최적화 된 페이지 대응 방법

<meta http-equiv="X-UA-Compatible" content="IE=7"/>

DTD가 혼재되어 있는 웹 사이트 대응법

<meta http-equiv="X-UA-Compatible" content="IE=7"/>

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>

호환 유도 코드를 서버측 응답 헤더에 적용하는 방법

X-UA-Compatible:IE=EmulateIE7

웹 표준 사이트와 낡은 브라우저의 호환성 문제

CSS Hack 활용하기

싱글턴 패턴(Singleton Pattern) - for Beginner

싱글턴 패턴의 개요

GoF의 23가지 디자인 패턴 중 개발자에게 가장 익숙한 패턴의 하나가 바로 '싱글턴 패턴(Singleton Pattern)'일 것이다. 싱글턴 패턴은 해당 클래스의 인스턴스(instance)가 하나만 만들어지고, 어디서든지 그 유일한 인스턴스에 접근할 수 있도록 하기 위한 패턴의로 정의된다.

GoF에 기술된 내용 중 싱글턴 패턴을 활용할 수 있는 상황은 다음과 같다.

• 클래스의 인스턴스가 오직 하나여야 함을 보장하고, 잘 정의된 접근 방식에 의해 모든 클라이언트가 접근할 수 있도록 해야 할 때.
• 유일하게 존재하는 인스턴스가 상속에 의해 확장되어야 할 때, 클라인트는 코드의 수정 없이 확장된 서브클래스의 인스턴스를 사용할 수 있어야 할 때.

이를테면 쓰레드 풀, 캐시, 대화상자, 사용자 설정이라든가 레지스트리 설정을 처리하는 객체, 로그 기록용 객체, 프린터나 그래픽 카드 같은 디바이스를 위한 디바이스 드라이버 같은 것들이 좋은 예가 될 것이다.

싱글턴의 기본적인 구조(Structure)는 그림과 같다.

싱글턴 패턴의 구조

멀티쓰레드 환경에서의 싱글턴(Multithreaded Singleton)

위에서 제기한 문제를 해결하기 위해서는 다음 세가지의 해법을 사용할 수 있다.

1. 인스턴스를 필요할 때 생성하지 않고, 처음부터 인스턴스를 만들어 버린다. 다시 말해서 lazy instantiation을 포기하고 static 멤버필드를 사용항여 언과 동시에 초기화하는 것이다.  단, 인스턴스를 미리 만들어 버리게 되면, 특히 해당 인스턴스가 자원을 많이 차지하는 컴포넌트일 경우에는 시스템 리소스가 쓸데없이 낭비될 가능성이 있다.
2. getInstance() 메서드(C#의 경우 Instance 속성)를 동기화시킨다. 단, 동기화시키고자할 때는 getInstance()의 속도가 그렇게 중요하지 않다고 판단될 경우이며 동기화로 인한 오버헤드를 감수해야 한다. - 메서드를 동기화 시키면 일반적으로 성능이 100배 정도는 저하된다고 한다.
3. DCL(Double-checked Locking) 기법을 사용한다. 단, 자바의 경우 DCL은 자바 5 버전 이상의 JVM 환경에서 인스턴스 변수에 volatile 키워드를 사용해야만 한다. voatile 키워드는 멀티쓰레드 환경에서도 uniqueInstance 변수가 원자성을 유지하도록 하여 올바른 싱글턴 인스턴스의 초기화가 진행되도록 한다(The volatile keyword in Java를 참고하라). 하지만 자바 1.4 및 그 이전에 나온 JVM에서는 메모리 모델의 문제로 제대로 동작하지 않는다는 것에 주의해야 한다(자세한 내용은 The "Double-Checked Locking is Broken" Declaration 참고하라).

설명보다는 코드를 보고 이해하는 것이 빠를 것 같다. 각 해법을 적용하여 멀티쓰레드 환경에서 제대로 동작(thread-safe)하는 싱글턴 구현의 예제 코드들이 아래에 있다.

1. 처음부터 인스턴스를 생성하는 예제 코드

[자바 코드 2]

public class Singleton {     private static Singleton uniqueInstance = new Singleton();         private Singleton() {}         public static Singleton getInstance() {        return uniqueInstance;     } }

[C# 코드 2]

public sealed class Singleton {     static readonly Singleton uniqueInstance = new Singleton();         // Explicit static constructor to tell C# compiler     // not to mark type as beforefieldinit     static Singleton()     {     }         Singleton()     {     }         public static Singleton Instance     {         get         {             return uniqueInstance;         }     } }

2. 동기화 예제 코드

[자바 코드 3]

public class Singleton {     private static Singleton uniqueInstance;         // other useful instance variables here          private Singleton() {}         public static synchronized Singleton getInstance() {         if (uniqueInstance == null) {             uniqueInstance = new Singleton();         }         return uniqueInstance;     }         // other useful methods here }

[C# 코드 3]

public sealed class Singleton {     static Singleton uniqueInstance = null;     static readonly object padlock = new object();     Singleton()     {     }     public static Singleton Instance     {         get         {             lock (padlock)             {                 if (uniqueInstance == null)                 {                     uniqueInstance = new Singleton();                 }                 return uniqueInstance;             }         }     } }

3. DCL(Double-checked Locking) 예제 코드

[자바 코드 4]

// // Danger!  This implementation of Singleton not // guaranteed to work prior to Java 5 // public class Singleton {     private volatile static Singleton uniqueInstance;         private Singleton() {}         public static Singleton getInstance() {         if (uniqueInstance == null) {             synchronized (Singleton.class) {                 if (uniqueInstance == null) {                     uniqueInstance = new Singleton();                 }             }         }         return uniqueInstance;     } }

[C# 코드 4]

public sealed class Singleton {     static Singleton uniqueInstance = null;     static readonly object padlock = new object();         Singleton()     {     }         public static Singleton Instance     {         get         {             if (uniqueInstance == null)             {                 lock (padlock)                 {                     if (uniqueInstance == null)                     {                         uniqueInstance = new Singleton();                     }                 }             }             return uniqueInstance;         }     } }

아래 C# 코드는 위 코드와 동일하게 DCL을 사용하지만 volatile을 사용하는 다른 버전의 예제이다.

[C# 코드 5]

public class Singleton {     private static volatile Singleton uniqueInstance = null;         protected Singleton()     {     }         public static Singleton Instance()     {         if (uniqueInstance == null)         {             lock (typeof(Singleton))             {                 if (uniqueInstance == null)                 {                     uniqueInstance = new Singleton();                 }             }         }         return uniqueInstance;          } }

싱글턴 레지스트리(Singleton Registry)

서두에서 "유일하게 존재하는 인스턴스가 상속에 의해 확장되어야 할 때, 클라인트는 코드의 수정 없이 확장된 서브클래스의 인스턴스를 사용할 수 있어야 할 때" 싱글턴을 활용한다고 하였다. 이때에는 서브클래스를 만드는 것이 중요한 게 아니라, 이 새로운 서브클래스의 유일한 인스턴스를 만들어 클라이언트가 이를 사용할 수 있도록 하는 것이 관건이다.

싱글턴의 서브클래스를 만들 때 가장 유연한 방법은 싱글턴에 대한 레지스트리를 사용하는 것이다. 아래 자바 예제 코드는 레지스트리를 갖고 있는 싱글턴으로 특정 클래스 객체의 인스턴스를 생성하기 위해서 리플렉션을 사용하고 있다. 'classname'은 Singleton의 서브클래스 이름이다. 이렇게 하면 서브클래스의 선택에 있어서 런타임에 싱글톤을 결정하는 유연성을 가질 수 있다(자세한 내용은 Simply Singleton을 참고하라).

[자바 코드 5]

import java.util.HashMap; import org.apache.log4j.Logger; public class Singleton {     private static HashMap map = new HashMap();     private static Logger logger = Logger.getRootLogger();     protected Singleton() {         // Exists only to thwart instantiation     }     public static synchronized Singleton getInstance(String classname) {         Singleton singleton = (Singleton) map.get(classname);         if (singleton != null) {             logger.info("got singleton from map: " + singleton);             return singleton;         }         try {             singleton = (Singleton) Class.forName(classname).newInstance();         }         catch(ClassNotFoundException cnf) {             logger.fatal("Couldn't find class " + classname);            }         catch(InstantiationException ie) {             logger.fatal("Couldn't instantiate an object of type " + classname);            }         catch(IllegalAccessException ia) {             logger.fatal("Couldn't access class " + classname);            }         map.put(classname, singleton);         logger.info("created singleton: " + singleton);         return singleton;     } }

결론

이상으로 멀티쓰레딩 환경에서의 싱글턴 패턴 구현 코드를 들여다 보았다. 그렇다면 이 세가지 중 어떤 코드 템플릿을 사용하는 것이 좋을까?

자바에서는 Double-checked locking과 Singleton 패턴 등 (조금 오래되긴 했지만) DCL과 관련한 문서들을 참고해보면 멀티쓰레드 환경에서 제대로 동작하는 싱글턴을 만들기 위한 최상의 솔루션은 동기화를 수락하거나 static 멤버필드를 사용하는 것을 권장하고 있다. 닷넷의 경우 The Correct Double Checked-Lock Pattern Implementation를 보면 [C# 코드 2]와 같은 형태의 코드를 사용할 것을 권장하고 있다.

싱글턴 구현에 있어서 반드시 DCL을 사용해야 하는 특별한 경우가 아니라면 대부분의 상황에서는 static 변수를 사용하거나 동기화 블럭을 사용하는 것으로도 충분할 것 같다. 성능의 저하는 다소 존재하겠지만 다양한 java  및 .net 버전과 메모리 모델에 종속적이지 않은 싱글턴을 구현하는 잇점도 있다고 생각한다. DCL을 적용해야한다면 특히 자바의 경우 volatile 키워드와 함께 반드시 자바 5 버전 이상을 사용해야 한다는 것을 잊지 말아야 한다.

마지막으로 참고가 될만한 두가지 사항을 덧붙이며 싱글턴 패턴에 대한 요약을 마무리한다.

싱글턴 패턴 사용 시 주의할 점(Java 기준)

• 중복되는 얘기지만 DCL을 사용하려면 자바 5(1.5) 이후 버전을 사용해야 한다.
• 클래스 로더가 여러개 있으면 싱글턴이 제대로 작동하지 않고, 여러 개의 인스턴스가 생길 수 있다. 이 경우 클래스 로더를 직접 지정해서 사용해야한다.
• 개인적으로 최근 프로젝트 환경을 보면 슬슬 자바 5 버전으로 많이 갈아타고 있는 듯 하다. 정말 오래된 시스템을 유지 보수하는 경우가 아니라면 자바 1.2 이전 버전을 사용할 일은 없겠지만, 혹시라도 자바 1.2 이전 버전의 환경에서 작업한다면 JVM의 가비지 컬렉터 관련 버그 때문에 싱글턴 레지스트리를 사용해야할 수도 있다.

아래 코드는 클래스 로더를 직접 지정하는 예제이다. 이 코드는 Class.forName() 메서드를 대체할 수 있다(자세한 내용은 Simply Singleton을 참고하라).

[자바 코드 6]

private static Class getClass(String classname) throws ClassNotFoundException {     ClassLoader classLoader = Thread.currentThread().getContextClassLoader();     if (classLoader == null) {         classLoader = Singleton.class.getClassLoader();     }     return (classLoader.loadClass(classname)); }

정적 클래스 변수(메서드) vs. 싱글턴 패턴

굳이 싱글턴 패턴을 사용할 필요없이 전역 클래스 변수(static 멤버필드)를 사용하면 되지 않을까 하는 의문이 들 수도 있다. lazy instantiation을 구현하는 싱글턴 패턴에 비해서 전역 변수를 사용하는 경우 다음과 같은 단점들이 있을 수 있다.

• 싱글턴 패턴은 static 인스턴스를 미리 생성해놓는 경우를 제외하고는 객체가 필요한 상황이 되었을 때에 비로소 인스턴스를 생성한다. 반면 전역 변수를 사용하면 대부분의 경우는 어플리케이션을 시작할 때 미리 객체가 생성한다. 그런데 그 객체가 자원을 많이 차지하고, 실제로 어플리케이션을 종료할 때까지 한번도 쓰지 않게된다면 괜한 자원만 낭비하는 꼴이 되고만다(이러한 상황은 시스템 플랫폼에 따라 달라질 수도 있다. 어떤 JVM은 객체를 나중에 필요할 때 생성하기도 한다고 한다).
• 전역 변수를 사용하다 보면 간단한 객체에 대한 전역 레퍼런스를 자꾸 만들게 되면서 네임스페이스를 지저분하게 만드는 경향이 생긴다. 물론 싱글턴도 남용될 수 있지만, 네임스페이스가 지저분해지게 되는 것을 부추길 정도는 아니다.

참고 자료

아래는 이 포스트를 작성하기 위해 참고한 도서와 관련 사이트의 목록이다. 영어가 짧고 스크롤의 압박이 심하다보니 사이트의 글들을 죄다 꼼꼼하게 읽어보지는 못했다. ^^; 하지만 정독해보면 분명 도움이 될 내용들이라고 장담한다. ^^

Books

• GOF의 디자인 패턴, 피어슨에듀케이션 코리아
• Head First Design Patterns, 한빛미디어
• 예제로 배우는 C# 디자인 패턴, 정보문화사 (비추. 자바와 닷넷 관련한 더 좋은 패턴 책들이 많이 있다.)
• J2EE 패턴 (GoF & J2EE), SUN SL-500
• The Design Patterns Java Companion

Terms

• The volatile keyword in Java
• Double-checked locking

Articles

• Double-checked locking과 Singleton 패턴
• 디자인 패턴으로 알아본 Double Checked Lock(DCL)
• The "Double-Checked Locking is Broken" Declaration 
• The Correct Double Checked-Lock Pattern Implementation
• Simply Singleton 
• Exploring the Singleton Design Pattern
• Implementing Singleton in C# 
• Performance of techniques for correctly implementing lazy initialization 

Abator는 iBATIS를 위한 코드 생성기이다. Abator는 데이터베이스의 테이블에 접근하기 위한 iBATIS 연관 코드들인 Object와 환경 설정 파일(configuration file)을 생성하며, 기본적인 CRUD(Create, Retrieve, Update, Delete) 쿼리를 포함한다.

Abator 설치를 위한 특별한 의존성은 없지만 다음 조건을 만족해야 한다.

• JRE 1.4 이상.
• DatabaseMetaData 인터페이스를 구현하는 JDBC 드라이버가 필요하다.

Abator가 생성하는 코드(파일) 목록은 다음과 같다.

• 테이블 구조에 매치되는 자바 POJOs
• iBATIS 호환 SQL Map XML 파일들
• DAO 인터페이스와 구현 클래스들

Abator 사용

1. 설정 파일 작성 - abatorConfig.xml

적절한 설정 파일을 생성한다. 설정은 적어도 다음 요소들을 포함하여야 한다(Abator 사이트 참고).

• A <jdbcConnection> element to specify how to connect to the target database
• A <javaModelGenerator> element to specify target package and target project for generated Java model objects
• A <sqlMapGenerator> element to specify target package and target project for generated SQL map files
• (Optionally) A <daoGenerator> element to specify target package and target project for generated DAO interfaces and classes (you can omit the <daoGenerator> element if you don't wish to generate DAOs)
• At least one database <table> element

다음은 abatorConfig.xml의 예제이다.

2. Abator 실행(Run)

커맨드 라인을 열고 다음과 같이 입력하여 Abator를 실행할 수 있다. 단, 설정 파일에 정의된 targetProject의 대상 디렉토리는 반드시 미리 존재해야 한다.

여기서 파라미터의 의미는 다음과 같다.

• 첫번째 파라미터: 환경 파일의 경로
• 두번째 파라미터: 파일이 이미 존재할 경우 overwrite 여부

abator 실행을 위한 간단한 배치 파일을 만들어 놓으면 편하다.  예를 들어 “abator.bat” 파일을 만들어 다음과 같이 편집한다.

3. Abator 실행 후 작업

다음과 같은 마무리 작업이 필요하다.

• SqlMapConfig.xml 파일을 생성하거나 편집한다.
• iBATIS DAO Framework를 사용할 경우, dao.xml 파일을 생성하거나 편집한다.

Abator로 생성된 코드 예제

1. Java Model Classes

Domain Class

Domain Example Classes

2. SQL Map Files

3. Java DAO Classes(optional)

DAO Interface

DAO Implement

참고 사이트

문제의 발생 - Memory Leak

• APM: Jennifer 3.2 (2주 평가판)
• Profiler: JProfiler 5.1 (10일 평가판)

Test 및 결과 요약

테스트 프로그램들을 작성하고 언급한 툴들을 활용하여 결과를 모니터링하였다. 프로그램은 쓰레드로 작성되었으며, 시작 버튼을 누르면 종료 버튼을 누르기 전까지 무한히 서비스를 호출하도록 하였다. 테스트는 개발 환경과 동일한 구성을 갖고 있는 1G 메모리(RAM)의 내 극빈한 M1 노트북에서 실행하였다.

자세한 상황과 과정을 모두 설명하기는 힘들지만, 대강 결론부터 얘기하자면 BaseService 에서 해당 작업을 종료할 때 호출하는 logging 메서드(작업에 대한 사용자 행위 추적을 구현) 부분에서부터 문제가 시작되었다.
 
BaseService에 대해 부연하자면, 모든 business logic을 구현하는 서비스들은 BaseServcie 클래스를 상속하도록 되어 있다. Controller와 유사한 역할을 한다고 봐도 무방할 듯 하다. UI(JNLP 클라이언트)에서 사용자의 액션 및 이벤트 등에 의해 발생하는 모든 서버 단 호출(Service Call)의 경우 호출 종료와 동시에 BaseServcie에 의해 logging 메서드가 호출된다. 하나의 이벤트에 의해 호출되는 서비스가 하나 이상이 될 수 있으므로 이 메서드는 호출 빈도수가 매우 높은 편에 속한다.

테스트 프로그램을 시작하면 BaseServcie 를 상속하는 서비스를 호출하게 되고 동시에 계속해서 logging 메서드가 호출되게 된다.

logging 메서드 호출부를 포함한 상태에서 테스트 프로그램을 실행하고 제니퍼로 모니터 하였다. 아래 그림은 문제 상황에서 제니퍼를 사용하여 메모리의 추이를 지켜본 것이다.

다음 그림은 위 그림과 동일한 시점에서의 GC로그 콘솔을 캡처한 화면이다.

 
다음은 동일한 조건과 시점에서의 GC 로그이다.

다소 안정되어 보인다.


원인 분석과 소스 수정


어플리케이션 실행 중 heap 상에 존재하는 객체들(실제 메모리의 Collection 및 Object들)을 대상으로 메모리 누수와 연관된 객체를 파악할 수 있다면 보다 확실하게 문제 코드에 접근할 수 있을텐데, 제니퍼 세팅이 잘못 되었는지 유일하게 Collelction에 대한 실시간 모니터링만 되지 않았다. 대신 JProfiler를 사용해서 확인하였는데, 아래 그림이 해당 화면을 캡처한 것이다.

 
그림으로는 잘 보이지않지만 java.lang.String 타입의 instance count가 1,496,688이고 char[] 배열 타입은 1,423,882개로 나타난니다. 이 둘(문자열)을 합친 메모리만 200M를 웃돌고 있다.

여기서 다시 메소드를 조사해보았다.

 
선택된 부분을 확대해서 보면 다음과 같다.

 
트리에서 선택된 노드는 LoggingService2.logging 메서드이며, 이것은 BaseService의 logging에 의해 호출된다. LoggingService2.logging의 두 단계 아래 노드를 보면 "DaoManagerBuilder.buildDaoManager" 메서드를 확인할 수 있다.

LoggingService2에는 DB에 로그 데이터를 기록하기 위해 DaoCofig로부터 DaoManager를 가져오는 부분을 필수로 포함하고 있다.

package com.ibatis.jpetstore.persistence;
 
import com.ibatis.common.jdbc.ScriptRunner;
import com.ibatis.common.resources.Resources;
import com.ibatis.dao.client.DaoManager;
import com.ibatis.dao.client.DaoManagerBuilder;
 
import java.io.Reader;
import java.sql.Connection;
import java.sql.DriverManager;
import java.util.Properties;
 
public class DaoConfig {
 
  private static final String resource = "com/ibatis/jpetstore/persistence/dao.xml";
  private static final DaoManager daoManager;
 
  static {
    try {
      daoManager = newDaoManager(null);
      Properties props = Resources.getResourceAsProperties("properties/database.properties");
      String url = props.getProperty("url");
      String driver = props.getProperty("driver");
      String username = props.getProperty("username");
      String password = props.getProperty("password");
      if (url.equals("jdbc:hsqldb:mem:jpetstore")) {
        Class.forName(driver).newInstance();
        Connection conn = DriverManager.getConnection(url, username, password);
        try {
          ScriptRunner runner = new ScriptRunner(conn, false, false);
          runner.setErrorLogWriter(null);
          runner.setLogWriter(null);
          runner.runScript(Resources.getResourceAsReader("ddl/hsql/jpetstore-hsqldb-schema.sql"));
          runner.runScript(Resources.getResourceAsReader("ddl/hsql/jpetstore-hsqldb-dataload.sql"));
        } finally {
          conn.close();
        }
      }
    } catch (Exception e) {
      throw new RuntimeException("Description.  Cause: " + e, e);
    }
 
  }
 
  public static DaoManager getDaoManager() {
    return daoManager;
  }
 
  public static DaoManager newDaoManager(Properties props) {
    try {
      Reader reader = Resources.getResourceAsReader(resource);
      return DaoManagerBuilder.buildDaoManager(reader, props);
    } catch (Exception e) {
      throw new RuntimeException("Could not initialize DaoConfig.  Cause: " + e, e);
    }
  }
 
}


JPetStore 예제에서는 getDaoManager()를 사용하여 정적으로 초기화된 단 하나의 DaoManager를 사용했지만, 프로젝트에서는 서브 시스템별로 dao.xml을 정의하고 각 시스템별로 달리 DaoManager를 사용하였으므로 모든 서비스 코드에서는 위에 기술한 바와 같이 DaoConfig의 newDaoManager() 메서드를 통하여 daoManager 인스턴스를 초기화하여 사용하였다.

public class SomeService extends BaseService {
 private DaoManager daoManager;
 private SomeDAO someDao;

 public SomeService() {
  daoManager = DaoConfig.newDaoManager(DaoResource.JobResName);
  this.someDao = (SomeDAO) daoManager.getDao(SomeDAO.class);
 }
 ...
}

참고로 BaseService 유형의 클래스들은 Servlet이 Container에 의해 관리되듯이 단 하나의 인스턴스로 존재한다.

여기서 잠시 iBatis DAO와 관련된 내용에 대해 언급하자면, iBatis DAO 프레임워크를 초기화하기 위해서는 dao.xml 파일 경로를 파라미터로 넘겨주어 DaoManagerBuilder.buildDaoManager()를 호출해야한다. DAO 프레임워크는 이 메서드에서 해당 dao.xml 파일을 읽고 상응하는 DaoManager를 생성하게된다. client는 이 DaoManger를 사용하여 insert 등과 같은 제반 작업을 수행하게 된다. 아래 그림을 참고하면 된다.

DAO sequence diagram (그림 참고)

앞서 설명했듯이, 테스트 프로그램은 문제 상황을 빨리 발생시키기 위해서 무한하게 트랜잭션을 발생시키는 형태를 취했지만 logging 메서드 자체가 매우 빈번하게 호출되는 구조임을 전제로 하고 생각해 볼 때,

일반적으로 특정 메서드의 블럭을 벗어나게 되면 메서드 내에서 지역변수로 사용한 객체는 Garbage Collection의 대상이 대상이 된다. 하지만, 설명한 바와 같이 DaoManagerBuilder.buildDaoManager()에서 dao.xml 파일에 대한 I/O가 일어나고 읽어들인 파일을 parsing하고 DaoManager의 인스턴스를 생성하는 작업을 수행하게 되는데, 결과로 미루어 볼때 어느 정도 시간 간격을 둔 상태에서는 별 무리 없이 수행되었지만, logging과 같이 짧은 시간에 많은 수의 서비스를 수행과 동시에 호출되는 경우 GC가 제대로 되지 못하고 결국 감당을 하지 못하게 되는 듯 하다. 추측컨데, JProfiler에서 보여진 수많은 문자열 관련 객체들은 반복되는 I/O와 parsing 작업의 부산물이라 여겨졌다.

이것이 원인이 맞다면, DaoManager를 초기화 하기 위해 매번 DaoConfig의 newDaoManager를 호출함으로써 빈번한 buildDaoManager 작업을 발생시킬 수 있는 개연성을 갖는 것을 미연에 방지하기 위해 DaoConfig 자체를 수정하는 것이 좋을 듯 했다.

따라서 근본적인 원인을 제공한 DaoConfig의 소스를 아래 코드와 같이 수정한 후 다시 프로그램을 실행하였다. DaoConfig는 싱글톤(singleton)으로 변경하고 각 업무단의 DaoManager를 Hashtable을 사용하여 cache 하도록 수정하였다. 캐슁으로 인한 부작용(?!)은 없을까 잠시 생각해보았는데 dao.xml을 리로드하기 위해서는 어차피 WAS를 재시작할 필요가 있었다. SQL Map 파일의 경우 절대 경로를 사용하여 자동으로 다시 로드 되게끔 되어 있다(개발서버의 경우만 해당).

다음이 대강의 코드이다.

public class DaoConfig {
 
  private static DaoConfig instance = null;
  private static Hashtable<String, DaoManager> daoManagers = null;
 
  private DaoConfig() {
    daoManagers = new Hashtable<String, DaoManager>();
  }
 
  public static DaoConfig getInstance() {
    if (instance == null) {
      instance = new DaoConfig();
    }
    return instance;
  }
 
  public DaoManager getDaoManager(String resource, Properties props) {
    DaoManager daoManager = null;
    if (daoManagers.containsKey(resource)) {
      daoManager = (DaoManager) daoManagers.get(resource);
    }
    else {
      try {
        Reader reader = Resources.getResourceAsReader(resource);
        daoManager = DaoManagerBuilder.buildDaoManager(reader, props);
        daoManagers.put(resource, daoManager);
      } catch (Exception e) {
        throw new RuntimeException("DaoConfig를 초기화할 수 없습니다. 원인: " + e, e);
      }
    }
 
    return daoManager;
  }
 
  /* 호환성을 위해 남겨둔 method들 */
  public static DaoManager newDaoManager(String resource) {
    return newDaoManager(resource, null);
  }
 
  public static DaoManager newDaoManager(String resource, Properties props) {
    DaoConfig config = DaoConfig.getInstance();
    return config.getDaoManager(resource, props);
  }
 
}

다시 프로그램을 실행하고 결과를 보여주는 제니퍼 화면을 캡처 하였다. 비교를 위해 이전의 화면들을 다시 붙였다. 수정된 코드가 반영된 결과 화면은 마지막 화면이다.

* 최초의 문제가 있던 상태

* logging 메서드를 호출하지 않은 상태

* DaoConfig를 수정한 이후 상태

 
훨씬 안정적인 상태로 변했다.
이 상태에서의 GC 로그는 다음과 같다.

 
결론적으로 DaoManager를 각각의 서비스 코드에서 매번 초기화하기 위해서 DaoConfig의 newDaoManager 메서드를 호출할 때, 빈번한 DaoManagerBuilder.buildDaoManager()가 호출되는 구조는 문제를 일으킬 여지가 있는 것 같다.

대강 정리를 마치고 내용을 한번 읽어보았는데, 정리가 제대로 된 것 같지는 않다. ^^;
아무튼 요는, 항상 기본에 충실하고 미리 생각하는 개발자가 되자! ^^


P.S. 잘못된 내용이 있다면 지적 바랍니다. ^^

참고

관련 API

• http://ibatis.apache.org/docs/java/dev/com/ibatis/dao/client/DaoManager.html
• http://ibatis.apache.org/docs/java/dev/com/ibatis/dao/client/DaoManagerBuilder.html
• http://ibatis.apache.org/docs/java/dev/com/ibatis/dao/engine/builder/xml/XmlDaoManagerBuilder.html
• http://kickjava.com/src/com/ibatis/dao/client/DaoManagerBuilder.java.htm
• http://kickjava.com/src/com/ibatis/dao/engine/builder/xml/XmlDaoManagerBuilder.java.htm

 

"Development Story" 카테고리의 다른 글

• WYSIWYG Web Editors (댓글 2개 / 트랙백 0개) 2009/12/16
• 개발자들도 헷갈리는 몇가지 용어들 (댓글 5개 / 트랙백 0개) 2009/10/27
• Maven 설치 요약 (Windows) (댓글 2개 / 트랙백 0개) 2009/10/27
• 프로젝트 후기 (댓글 2개 / 트랙백 0개) 2009/10/05
• Programming Fonts - 나눔고딕코딩 글꼴 등 (댓글 7개 / 트랙백 1개) 2009/09/18