SQL Server 와 Oracle 10g(11g) 과의 분산트랜잭션(Distiributed Transaction) 구성

SQL Serer 에서 linked serer로 구성된 Oracle 10g(11g) 서버와의 분산트랜잭션(2pc)을 수행하도록 하려면 다음과 같은 내용을 점검해 보아야 한다.

[SQL Server 상에서]
1. SQL Server 박스에 DTC 가 활성화 되어야 한다.
분산 트랜잭션이 수행될때는 이 DTC가 활용된다. 그래서 반드시 이 서비스가 활성화 되어야 한다.
그리고, Oracle 과의 트랜잭션 호환성을 위해 다음과 같이 설정하라.


오라클과는분산 트랜잭션 인터페이스로 XA 트랜잭션을 사용한다.
XA 트랜잭션 사용에 체크하고, 트랜잭션 관리자 통신내에서 인바운드 허용과 아웃바운드 허용 그리고 인증 필요 없음에 체크한다.

2.RPC port 가 오픈되어 있는지 확인 하라.
요즘은 대부분 하드웨어적인 방화벽 내지는 윈도우에 내장된 방화벽을 운영하고 있는데
분산 트랜잭션은 RPC를 통해 처리 된다. 이 RPC port가 방화벽에서 Oracle 서버에 열려 있는지 확인하라.
이때, 주의 할 것은 RPC 통신은 RPC 종단점(endpoint)이 특별히 지정되어 있지 않고, 열려있다는 것이다. 따라서, RPC 종단점 맵퍼(endpoint mapper) 서비스(135 번)을 통해 rpc endpoint를 지정하게 된다.
사실, endpoint를 지정하지 않으면 기본값으로 1024 ~ 5000 번 까지 동적으로 활당된다.

그러므로, 우리가 열어야 할 포트는 135 과 rpc endpoint 범위가 된다.
http://support.microsoft.com/kb/908472

또한 특별히 지정하지 않으면이라 말은 그 범위를 지정할 수 있다는 것을 말하고 다음 MSDTC 설정에서 지정할 수 있다.

3. Oracle Client 설치
Oracle client 를 설치할때 주의할 것은 반드시 Oracle Services For Microsoft Transaction Server 컴포넌트를 설정했는지 확인한다.
이 컴포넌트가 설치되지 않으면 Oracle 과의 분산 트랜잭션이 수행되지 않는다.

또한 Windows 가 2008이라면 Oracle 11g Client를 설치할 때는 특별한 문제가 없겠지만
Oracle 10g client 를 설치하고자 할 경우 다음과 같이 OS 호환성 체크에서 오류가 발생해
인스톨이 진행되지 않을 수도 있다.

Version is 6.1 and only Versions: 5.0,5.1,5.2 or 6.0 are valid.

6.1 OS 가 누락되어서 발생하는 문제이니, 이때는 당황하지 말고 oraparam.ini 파일에서
다음과 같이 6.1 버전을 추가하라.

CERTIFIED_VERSION_FAILURE_MESSAGE

Windows = 5.0,5.1,5.2,6.0,6.1

[Windows-6.1-required]

# Minimum display colours for OUI to run

MIN_DISPLAY_COLORS = 256

# Minimum CPU speed required for OUI

# CPU = 300

[Windows-6.1-optional]

4. 분산트랜잭션 테스트

위 쿼리가 성공하는지 점검하라. 오류가 발생한다면
linked server 구성옵션을 점검하라.

Server option에서 RPC, RPC 내보내기가 설정되어야 한다.

[Oracle 서버 상에서]
5. Oracle 서버상에서는 SQL Server 로 135 으로의 텔넷 테스트와 RPC endpoint 범위의 시작점과 끝점에 텔넷테스트를 수행해 접속이 되는지 점검하라.

6. 기타 고려사항

DB 응용프로그램에서 분산트랜잭션을 사용하는 방법은 크게 두가지가 있다.
1. COM+ 을 이용한 방법
2. .NET 2.0 이상에서 System.Transaction을 사용하는 방법

여기서 System.Transaction 의 TransactionScope 객체를 이용할 때는 Local Tx와 2 PC를 스스로 판단하여 Transaction을 수행하기에 성능상의 이점이 있다.

또한, 위 2가지 방법 모두 분산트랜잭션을 수행할때 트랜잭션 고립화 수준이
기본값으로 최 상위인 Serializable임을 알아야 한다.

이것은 트랜잭션이 완료될때가지 범위내에 공유잠금이 풀리지 않는 것을 의미하고, 해당 범위에 데이터를 삽입할 수 도 없다. Lock정보에는 RangeS-S 로 나타나게 된다.

만약, 트랜잭션이 짧게 끝나지 않고 오래동안 지속된다면 이것은 분명 시스템의 응답시간을 떨어뜨리는 원인이 된다. 특히 Update 성 작업과 맞물려 교착상태에 빠트리게 하기도 한다.

그러므로, 분산 트랜잭션의 업무의 특성을 파악하고
가능한한 업무로직을 짧게 가져가고, 필요한 경우 트랜잭션 고립화 수준을 Read committed 로 조정하라.

[COM+의 선언적 트랜잭션을 사용하는 경우]
[Transaction(TransactionOption.Required, Isolation = TransactionIsolationLevel.ReadCommitted)]

[System.Transaction을 사용하는 경우]
TransactionOptions options = new TransactionOptions();
options.IsolationLevel = IsolationLevel.ReadCommitted;
using(TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, options))
{...}

HTTP Compression

HTTP Compresssion
요즘과 같이 네트웍이 빨라진 시대에 HTTP 압축이 무슨 도움이 될까? 하는 생각도 하겠지만, 실상은 여전히 유용하다고 볼 수 있다. google.com이나, yahoo.com 혹은 유수한 포털의 Http Header 정보를 보게되면, HTTP 압축을 사용하고 있는 것만 보더라도 그것을 입증해 준다.

이 글로 HTTP Compression을 어떻게 사용하는지, 설정은 어떻게 하는지 알아 보자.
우선 HTTP 압축을 위해서는 Web Server와 Web Client(Browser) 두 영역에서 압축을 지원해 주어야 한다. 오늘날 대부분의 WEB Server(IIS, Apache, Tomcat...)는 이 HTTP 압축을 지원하고 있고, 클라이언트인 IE 나, FireFox 또한 기본적으로 압축을 지원하고 있어 HTTP 압축을 쉽게 사용할 수 있다.


HTTP Compression Activity

일단 HTTP 압축을 사용하기 위해 Client 와 Server 간에 어떤 행위가 일어나는지 살펴보자.
HTTP 압축을 사용하기 위해 Client가 해야 할 행위는 HTTP Header 에

Accept-Encoding: gzip, deflate

위 속성을 정의해 주면 끝이다. 이것은 하나의 약속으로, 클라이언트가 압축을 받아들일 준비가 되어있다는 의미이다. 즉, 브라우저에 압축을 해제할 수 있는 모듈이 탑재되어 있어, 서버가 HTTP 를 압축해서 던저줘도 된다고 선언하는 것이다.
오늘날 대부분의 클라이언트(IE, FireFox)는 이를 자동으로 설정한다.

그리고 나서, 서버가 할 행위는, 요청을 받아 들이고 처리해서 그 내용을 gzip 을 통해 압축해서 다시 클라이언트에 전송해주는 일이다. 이때 Server 는 HTTP Header에

Content-Encoding: gzip

을 설정해서 client 로 보내주며, client 는 이에 대응하는 압축해제를 하게된다.


HTTP Compression Configuration

여기에서, HTTP Compression 설정은 IIS 6.0기준으로 설명하기로 하며, Apache나 Tomcat, Was에 대한 설정은 별도로 수행해 보라.

IIS에서 HTTP 압축은 설정은 "인터넷 정보서비스(IIS) 관리"에서 설정할 수있다.

"IIS 관리"에서 --> "웹사이트"를 선택하고, 속성(properties) 선택 --> "웹사이트 등록정보" 화면창에서 "서비스" 탭을 선택한다. 다음과 같은 화면이다.

















하단에 HTTP 압축 항목이 보인다.
두가지 체크박스가 있는데, "정적 파일 압축"은 확장자가 html, htm, txt 같은 정적파일을 압축하는데 사용되며, "응용 프로그램 압축"은 기본적으로 asp, dll, exe 파일을 압축하는데 사용된다.
이 U.I 에서 설정된 정보는(다른 IIS 설정정보도 마찬가지겠지만..) %windir%\system32\inetsrv\MetaBase.xml 파일에 저장된다.

사용하고자 하는 항목을 체크하고 "확인"을 선택하면 이제부터 HTTP 압축을 사용할 수가 있다.이것이 끝이 아니다, 지금부터는 안좋은 소식이다.
ASP.NET 사이트를 운영하고 있고 Fildder 같은 유틸로 오고가는 HTTP Header를 보면 IIS에서 HTTP 압축을 설정했지만 여전히 내용이 압축되지 않는다는 사실을 알게된다. 정말 당혹스럽다.왜그럴까?
위에서 잠깐 언급해지만, "응용프로그램 압축" 의 기본 확장자가 asp, dll, exe 임을 주목하자.
맞다. 참으로 어처구니 없게도 aspx 가 제외되어 있다.
버그인지... 그들의 의도를 알수 없는 대목이다. 어쨋든 인간이 하는일에 있어 완벽한 일이 어디 있겠는가? 실수라고 생각하자. 그러는 것이 건강한 이성을 유지하는 길이다.

어쨌든, 원인을 알았으니 해결할 수 있다. 지금 부터는 손의 수고가 필요하다(사실 결정적인 상황에서 손이 필요한 경우가 종종있다.)
위에서 IIS 설정값이 %windir%\system32\inetsrv\MetaBase.xml 에 저장된다고 했다.
이 파일을 열어 다음과 같은 엘러먼트를 찾는다.



어트리뷰트중 HcScriptFileExtensions aspx 확장자를 추가한다. 내 경우는 다음과 같다.



그리고 한가지 더, HcDynamicCompressionLevel 이란 속성이 있는데, 이것은 압축 수준을 결정한다.
0~10 까지 설정할 수있다. 압축율이 높다면, 응답성능이 조금 떨어지는 것은 당연하다.


XMLHTTP 와 HTTP Compression

XMLHTTP 는 크게 두가지로 나뉜다.
wininet.dll을 사용하는 XMLHTTP, winhttp.dll을 사용하는 ServerXMLHTTP이다.
차이점은 차후에 알아 보기로 하고, 서버에서 사용하는 ServerXMLHTTP는
HTTP Header를 설정할 수 없기에 압축을 지원하지 않는다.

하이퍼스레딩 (Hyper-Threading) 사용할 것인가 말것인가?

SQL Server 혹은, .NET 이나 J2EE applicadtion 환경에서 인텔 계열 CPU를 사용할 때 Hyper-Threading이 과연 어떠한 영향을 미치는지 생각해 보도록 하자

• Hyper-Threading이란?

먼저 Hyper-Threading 이라 부르는 이 인텔의 cpu 기술은 multi-thread기술을 CPU layer에 도입한것이지만 실상 이것과는 다른다. 이것은 시분할 처럼 thread의 인터리빙 방식이 아니라 cpu 아텍처상 길게 늘어진 pipeline을 통해 있는 비어있는(놀고) 사이클을 다른 프로세스에게 사용할 수 있는 기회를 주는 것이다. 다시 말해서 현재 어떤 쓰레드가 RAM 액세스나 I/O 액세스 같은 오랜 시간이 걸리는 작업이 끝나기만을 기다리고 있다면 이를 다른 쓰레드에 할당하여 cpu의 활용도를 높이는 기술이다.
통상 Hyper-Threading을 사용하면 5% ~ 15%의 성능 향상을 기대할 수 있다.
하지만 이게 다가 아니다. 이 기술의 이면에는 조금은 깊게 생각해야할 성능적 문제가 자리잡고 있다.

• Hyper-Threading의 성능문제

위에서 설명한 대로 hyper-threading 기술은 놀고있는 cycle를 다른 쓰레드에게 할당해주는 방식이기에 마치 2개의 cpu 처럼 보일 뿐이지, 물리적으론 하나다. 그 말은 L1&L2 캐쉬를 공유한다는 의미이다. (마치 다중 thread가 프로세스내의 메모리를 공유하는것가 동일하다)
문제는 여기에서 출발한다.
Thread는 크게 두개로 나눌수 있다. 하나는 사용자의 요청을 처리하는 worker thread이고 , 다른 하나는 system thread로 백그라운드로 수행되는 쓰레드인데, GC나 Lazy writer 같은 것이 이에 해당한다. 왜 이것을 말하냐 하면, worker thread는 비교적 작은 단위 작업을 처리하는데 비해 백그라운드 쓰레드는 대용량 메모리나/object/cache 를 스캔하거나 하는 작업이 이루어 진다.
다음과 같은 시나리오를 생각해보자.
만약 동일한 물리적 CPU 안에서, worker thread가 작업을 수행 하다가 i/o 를 처리하기위해 대기 하고 있는데 이때 system thread가 수행되어 대용량 메모리 스캔을 위해 CPU를 할당하면 대용량 작업을 수행하기 때문에 공유된 L1&L2 캐시를 지워버린다. 다시 worker thread로 돌아와서 나머지 작업을 처리할려고 하니 이미 L1&L2 캐시에 없기 때문에 cache miss가 발생하고, 보조 기억장치인 RAM을 뒤지고, 여기에도 없다면 disk page i/o가 발생하게 된다.
이와같은 상황은 부하가 매우 높은 시스템에서라면 심각한 성능저하를 일으킬 수 있다.

또한 이런 시나리오는 SQL Server 환경이나, .NET, J2EE환경에서는 빈번하게 발생된다.
특히 SQL Server환경이라면, Lazy writer 뿐만아니라, worker thread 자체가 대용량 메모리를 스캔할수도있다(인덱스 부재로).

• 그럼 Hyper-Threading을 사용하지 말아야 하나?

그것은 아니다. 앞서 말한데로 Hyper-Threading 을 사용한 성능향상은 분명이 존재한다.
그리고 이것은 사용하고 있는 application 이나, 시스템 환경에 따라 달라진다.
또한 시나리오에 따른 성능저하 현상은 매우 높은 시스템 부하에서만이 확인해 볼수 있다.
따라서 우리 시스템에서 Hyper-Threading을 사용할지 말지는 그 시스템의 환경에 따라
충분한 테스트를 수행하고 나서 결정을 해야한다.

그것이 SQL Server라면, 메모리가 충분한지(lazy writer), 그리고 인덱스가 적절히 사용되어 대용량 메모리 스캔이 드물다면, 또한 heavy load가 아니면 개인적인 생각으로는 사용하는 것이 좋다고 판단한다.

이것에 관한 sql server 개발자의 의견은 많은 도움을 줄것이다..

Hibernate Persistance status

예전에 공부하면서 정리해 둔 내용..

1.1. The persistence Lifecycle

1.1.1. Transient Objects
일반 자바 instance로 Database table의 row와 아무런 관련이 없다.
다른 객체가 더 이상 이 객체를 참조하지 않는다면 garbage collection 에 의해 소멸된다.
Hibernate 에선 모든 transient object를 non-transaction 상태로 다룬다. 따라서 이 객체의 상태 변화는 transaction context와 무관하다. 또 이 객체에 대한 rollback 기능도 제공되지 않는다.

이 transient 객체가 영속성을 가지려면 persistence manager에서 save() 가 호출하거나, 이미 persistent 상태에 있는 인스턴스로부터 참조를 생성해야 한다.

1.1.2. Persistent Objects
Persistent 인스턴스는 database 의 식별자인 primary key 값을 가지는 아무 인스턴스이다.
Persistent 인스턴스란 application 에서 객체가 인스턴스화 된 다음, persistent manager(session )의 save() 메소드 호출에 의해 영속성을 가지게 된다.
또, 이미 persistent manger와 연관된 다른 persistent 객체로부터 참조가 생성된 객체도 영속성을 가지게 된다.

Persistent 인스턴스는 transaction에 참여되고, 그 인스턴스의 상태는 트랜잭션의 끝에서 database와 동기화 된다.
트랜잭션이 commit 되면, 메모리에 보관된 상태는 sql 명령문 insert, update, delete 이 수행되어 database에 전달된다. à 이것은 session.close()가 호출될 때 수행된다.

1.1.3. Detached Objects
트랜잭션이 완료될 때, Transaction manager와 관련된 persistent 인스턴스는 여전히 존재한다. 다시 말해 session.close() 가 호출될 때 더 이상 이 인스턴스는 persistent 상태가 아니지만, 여전히 그 인스턴스의 상태를 참조할 수 있는데 이러한 상태를 detached 상태라 한다.
이 상태에서는 더 이상 database와 동기화가 수행되지 않는다. (hibernate의 관리를 받지 않는다)

1.1.4. Implementing equals() and hashCode()
.Object identifier Vs database identifier
.가장 좋은 해결책 à business key(surrogate) 대리 키를 사용한다.
왜냐면, 집합 내에서 유일해야 하면, 또한 이 키의 변경이 자주 일어나지 않는 게 좋다.

1.2. The persistence manager

1.3. Using transitive persistence in Hibernate
1.3.1. Cascading persistence with Hibernate
Hibernate는 cascade 스타일을 각 association mapping 에 명시할 수 있다.
이렇게 선언된 cascade 스타일을 읽고, association 된 객체의 cascade를 자동으로 수행한다.
각 객체 mapping 에 이 cascade 스타일을 따로 지정할 수 있다.

기본적으로 hibernate는 transient, detached 인스턴스와 관련은 cascade를 사용하지 않는다.
- cascade=”none” à 기본값으로 association을 무시한다.
- Cascade=”save-update” à save(), update() 와 관련된 트랜잭션이 완료될 때 association을 탐색한다.
- Cascade=”delete” à delete() 수행 될 때, persistent를 삭제하고 관련된 객체를 탐색한다.
- Cascade=”all” à save-update, delete를 포함하고, evict(), lock()이 호출될 때 도 수행.
- Cascade=”all-delete-orphan” à all과 같고, 추가로 관계가 삭제된 persistent entity도 함께 삭제
- Cascade=”delete-orphan” à 연관관계가 삭제된 아무 persistent entity 는 삭제한다.

아가 이름

"이안"의 이름을 짓는 과정에 사용한 마인드맵(브래인스톰)

조금은 즉흥적으로 아이의 이름을 결정하였지만, 짓고 나서 그 의미를 다시 생각해봤을때, 이 처럼 이 아이의 이름에 완전하게 어울리는 이름은 없을 것이라는걸 깨달았다. 왜냐하면, 그는 우리에게 주신 하나님의 평안 그 자체였기 때문이다...

세 가지 질문

"세상에서 가장 중요한 때는 바로 지금, 이 순간이고,
가장 중요한 사람은 지금 함께 있는 사람이고,
가장 중요한 일은 지금 내 곁에 있는 사람을 위해 좋은 일을 하는 것"이라고 했다.

톨스토이의 글을 통해 난 참 많은 감동을 받는다..
그의 사상과, 고뇌 그리고 삶의 여정은 누군가에게 영향력을 끼치기에 충분한 것 같다..
무엇보다 그의 깊은 고통과 사색으로 부터 나오는 통찰력은 내가 누리고 있는 것들에 대한
또 다른 반증이 되기도 하고 삶에 대하는 나의 태도를 다시 추스릴 기회를 제공한다.

백년을 산다고 해도

백년을 산다고 해도 육체의 삶은 무척 짧다
이 모든 사실을 깨닫고 나서 나는 사랑하는 사람들과
부딪치느라 내 시간을 낭비하지 않기로 결심했다
나는 그들을 즐기고 싶다
그들이 어떤 생각을 갖고 있는지를 알아내려하기 보다는
그저 있는 그대로의 그들을 사랑하고 싶다

그는...

그는 아무도 나를 사랑하지 않을 때
조용히 나의 창문을 두드리다 돌아간 사람이었다.
그는 아무도 나를 위해 기도하지 않을 때
묵묵히 무릎을 끓고
나를 위해 울며 기도하던 사람이었다.
내가 내 더러운 운명의 길가에 서성대다가
드디어 죽음의 순간을 맞이했을 때
그는 가만히 내 곁에 누워 나의 죽음이 된 사람이었다.
아무도 나의 주검을 씻어주지 않고
뿔뿔이 흩어져 촛불을 끄고 돌아가버렸을 때
그는 고요히 바다가 되어 나를 씻어준 사람이었다.
아무도 사랑하지 않는 자를 사랑하는
기다리기 전에 이미 나를 사랑하고
사랑하기 전에 이미 나를 기다린.
-정호승

나에게 축구는 '전투'였는데 아들 두리는 '행복한 생활'

한국에서 우리 부자의 얘기가 화제라고 한다. 도대체 뭐가 재밌다는 건지 나로서는 이해가 잘 안 갈 뿐이다.
젊은 세대, 그들의 생각과 감각을 이렇게 이해하지 못하면서 내가 그들과 함께 몸을 섞고 일을 하고 있는 게 맞는 일인지 걱정스러울 정도다.
요즘 TV에 나와 정신없이 떠드는 녀석이 하나 있다. 노홍철이라고. 몇 년 전, 우리 가족의 크리스마스 파티에 이 친구가 왔다. 큰딸(하나) 대학 동기의 남자친구라고 하면서. 쓸데없는 얘기지만, 딸의 대학 동기는 유로 상공회의소를 거쳐 G그룹의 경영전략실에 근무하는 멀쩡한 재원이다. 도무지 어울리지 않는 이 남자친구를 보자 기가 막혔다. 그런데 아이들은 재미있어 좋다고 했다. 같은 시대를 살면서도 이해하기 힘든 세대차이다. 그래서 나는 지금의 상황이 노홍철이를 처음 봤을 때만큼이나 곤혹스럽고 불편하다.
나는 10년간의 독일 분데스리가 생활 중 선발로 못 나온 게 딱 두 번 있었고, 중간에 교체돼 나온 게 한 번 있었다. 그땐 하늘이 무너지고 땅이 꺼지는 줄 알았다. 내가 얼마나 심하게 낙담을 했으면 감독이 그 다음 경기 전에 나를 불러 이렇게 말할 정도였다.
"다음부터 너를 빼려면 미리 말해줄 테니까 아무 걱정하지 말고 뛰어라!"
그 당시 나에게 축구는 생활이 아니라 '밀리면 끝나는 전투'였던 것 같다. 그런데 아들 두리는 확실히 다르다. 축구는 '자신을 행복하게 해 주는 생활'인 것 같다. 축구를 하는 것만으로도 너무나 좋은.
그러니 TV 해설을 하면서 이놈은 "전 그때 후보라서 잘 몰라요"라고 멀쩡하게 얘기하는데 옆에 있는 내가 진땀이 났다.
내가 두리에게 배우는 게 하나 있다. 언젠가 자전적인 글에도 썼던 적이 있지만 '남의 행복이 커진다고 내 행복이 줄어들지는 않는다'는 것이다. 그래선지 이 녀석은 항상 여유가 있다. 늘 최고여야 한다는 강박관념 때문에 남을 인정하는 여유가 없는 나에 비해 두리는 동료를 인정하는 여유가 있다. 그래서 두리의 삶이 나보다 더 즐거운 모양이다.
'행복이'.
두리의 e-메일 닉네임이다. 굳이 그런 이름을 쓰는 걸 보면 천성이라기보다는 행복하고 싶어 스스로 하는 노력인지도 모르겠다.
마치 우리나라 젊은이들이 연예인들을 얘기하듯, 외국 축구선수들의 사생활까지 줄줄 꿰는 두리가 옆에 있으니 든든하다. 스페인의 황태자비가 화면에 잡히자 '예쁘죠?'하는 말이 하고 싶어서 혼났다며, 중계를 마치자마자 황태자비의 전력에서부터 사생활까지 쫙 얘기해 준다.
두리와 함께 해설을 해야겠다고 마음을 정한 이유가 여러 가지 있지만 한때 '기자'를 꿈꿀 정도로 다방면에 관심이 많은 두리에게 도움을 받고 싶었던 것도 그중 하나였다. 나는 지난 몇 년 동안 이전처럼 유럽축구에 많은 관심을 가질 수 없었다. 축구의 흐름을 읽는 거야 자신이 있지만, 선수들의 현재 상황을 팬들에게 현실감 있게 설명해 줄 경험과 정보가 부족했다.
내가 생각했던 것보다 두리는 훨씬 더 많이 알고 있었다. 또 나와 다른 요즘 아이들의 생각도 들을 수 있었다. 물론 친구들의 얘기를 하는 것이니 내가 하는 것보다 자연스러웠다.
그러나 본인도 분데스리가에서 뛰는 축구선수이면서 베컴의 자서전을 머리맡에 놓고 잠들거나 지단에게 가서 공에 사인을 받고는 즐거워하는 것은 여전히 이해하기 힘들다. 나는 그러지 않았다. 상대가 아무리 대단한 선수였어도 나에게는 한번 붙어 보고 싶은 경쟁자일 뿐이었다.
우리 시대의 삶은 '성공'에 모든 것을 두었다. 그러나 두리가 살고 있는 지금은 '행복과 즐거움'이 그들의 중심에 있는 것 같다.
부럽다. 그리고 이런 세상을 그들에게 물려준 우리 세대가 자랑스럽다

OOP, DataSet? 이 둘의 애증관계..

근래에 몇명의 .Net 응용프로그램을 보다가 DataAccess Layer에 관한 특이한 점을 볼수있었다.
객체지향 언어를 사용하고는 있지만 비 객체지향 프로그램을 한다는 점인데, 특별히 DataSet의 사용이 그 중심에 있는것 같다. 난 플렛폼(.Net이든 Java든)을 떠나 OO 원칙을 바르게 지켜나가는것이 중요하다고 생각한다. DataSet 사용이 왜 OO적이지 않은것인가?. 잠시 생각을 빌려달라.

DataSet은 그 자체로 하나의 객체(object)이다. 하지만 이것을 사용한다고 해서 자동으로 이를 사용하는 다른 것들이 객체지향적이 되지는 않는다. 다음과 같은 비유를 들어보자.
누군가 식당에 가서 스파게티를 주문했다고 하자. 잠시 후 점원이 가져다 준것은 스파게티가 아니라 엉뚱하게도 스파게티를 만들수 있는 재료를 그릇에 담아 준것과 비슷한 것이다. 친절한 주방장은 입맛에 맞게 직접 요리해 먹으라고 가져다 준것일 수도 있지만 배고픈 그가 정말 원한 것은 요리된 스파게티이다. 마찬가지로 DataSet은 재료를 담은 용기이지 고객에게 건내줄 최종적인 사용자 객체가 아니다.

DataSet을 최종적인 사용자에게 던저 준다는 것은 조리법을 그들에게 떠 넘기는것과 마찬가지이다. 이 말은 곧 데이터 로직을 프리젠테이션 노출한것 결과과 되고 Data-Tier와 Presentation-Tier가 커플링되어 유연하지 못한 구조가 된다. (n-Tier 원칙상 각 계층은 다른 계층에 독립적이어야 하며, Presentation-Tier는 Data-Tier를 직접적으로 접근할수 없고, 반대로 Data-Tier도 Presentation-Tier에 접근할 수 없다. 오직 중간에 계층인 Business-Tier가 이 둘 사이의 가교역활을 할 수 있다.)
이런 결과로 인한 부작용은, 프로젝트 경험이 있는 누구나가, 수도없이 겪었을 터이라 따로 말하지 않겠다.

그럼 대안은 무엇인가? 본질로 돌아가 객체지향에 충실한것이 좋은 선택이라 본다. 즉 DataSet 대신 사용자 엔터티(Custom Entity 혹은 Business Entity)를 사용하는 것이 OO 적인 이점을 충분히 누릴수 있다. 다시 말해 주문한 스파게티를 먹는 사람은 맛있게 먹어 배고픔을 달려면 그뿐이다. 고객이 스파게티를 맛있게 만드는 조리법을 익혀 스스로 만들필요가 없다는 것이다.
결국 최종 객체를 사용하는 클라이언트는 자신의 업무영역에 해당하는 문제에 좀더 노력을 집중할 수가 있어, 생산성이 향상된다.

이런 고민중에 다음과 같은 글을 보게되었다. 기나긴 가뭄끝에 만나는 단비마냥 그렇게 반가울수가 없다.
사용자 지정 엔터티 클래스 소개

engineeringhumor

Dilbert's Salary Theorem

Dilbert's "Salary Theorem" states that "Engineers and scientists can never earn as much as business executives, sales people, accountants and especially liberal arts majors." This theorem can now be supported by a mathematical equation based on the following two well known postulates:
Postulate 1: Knowledge is Power. Postulate 2: Time is Money. As every engineer knows: Power = Work / Time.
Since: Knowledge = Power, then Knowledge = Work / Time, and Time = Money, then Knowledge = Work / Money.
Solving for Money, we get: Money = Work / Knowledge.
Thus, as Knowledge approaches zero, money approaches infinity, regardless of the amount of work done


WRITE IN C ("Let it Be")
When I find my code in tons of trouble,
Friends and colleagues come to me, Speaking words of wisdom: "Write in C."
As the deadline fast approaches, And bugs are all that I can see,
Somewhere, someone whispers: "Write in C." Write in C, Write in C,
Write in C, oh, Write in C. LOGO's dead and buried, Write in C.
I used to write a lot of FORTRAN, For science it worked flawlessly. Try using it for graphics!
Write in C. If you've just spent nearly 30 hours,
Debugging some assembly, Soon you will be glad to Write in C.
Write in C, Write in C,
Write in C, yeah, Write in C. BASIC's not the answer. Write in C.
Write in C, Write in C Write in C, oh, Write in C. Pascal won't quite cut it.
Write in C.

ㅋㅋㅋ
다음 또 하나

Real Engnieers.
1. Real Engineers consider themselves well dressed if their socks match.
2. Real Engineers buy their spouses a set of matched screwdrivers for their birthday.
3. Real Engineers wear mustaches or beards for "efficiency". Not because they're lazy.
4. Real Engineers have a non-technical vocabulary of 800 words.
5. Real Engineers think a "biting wit" is their fox terrier.
6. Real Engineers know how to take the cover off of their computer, and are not afraid to do it.
7. Real Engineers know the second law of thermodynamics - but not their own shirt size.
8. Real Engineers repair their own cameras, telephones, televisions, watches, and automatic transmissions.
9. Real Engineers say "It's 70 degrees Fahrenheit, 25 degrees Celsius, and 298 degrees Kelvin" and all you say is "Isn't it a nice day"
10. Real Engineers give you the feeling you're having a conversation with a dial tone or busy signal.
11. Real Engineers wear badges so they don't forget who they are. Sometimes a note is attached saying "Don't offer me a ride today. I drove my own car".
12. Real Engineers' politics run towards acquiring a parking space with their name on it and an office with a window.
13. Real Engineers know the "ABC's of Infrared" from A to B.
14. Real Engineers rotate their tires for laughs.
15. Real Engineers will make four sets of drawings (with seven revisions) before making a bird bath.
16. Real Engineers' briefcases contain a Phillips screwdriver, a copy of "Quantum Physics", and a half of a peanut butter sandwich.
17. Real Engineers know that Halloween is really the same as Christmas, because OCT 31 = DEC 25. (If you _don't_ get it, then you're not a Real Engineer.)
18. Real Engineers don't find the above at all funny.

엔지니어 자질을 가진 당신 정말 그렇지 않나? ^^

시작으로 부터...

생각의 시작으로 부터 움직이는 것들...