XML 관련 작업중에 별 생각 없이 org.apache.xerces.jaxp.DocumentBuilderFactoryImpl 참조해다 썼는데,
이런 된장찌게..
배포 패키지를 만들어서 AIX(5.3)에 배포 후 실행 시켰더니, 저놈을 찾지 못한다는 예외가 떨어졌다.
IBM jre 는 이전부터 자주 말썽을 일으켜온(아니 말썽이라기보단 주로 SUN jdk로 개발을 해 오던 세월들이니 항상 귀찮았을수 밖에.. 핑계인거다 -_-+) 이력이 있으니,
'아놔 또..' 라고 OS 탓을 투덜투덜.
그래도 이번엔 나이가 좀 든 탓인지.. 대체 왜이러나 좀 알아두고 넘어가야 하겠다는 생각이 들어 구글링을 좀 했더니, 쓸만한 정보가 좀 나왔다.
원래 SUN jre(1.4) 에서 org.apache.xerces 라는 놈은 /lib 의 rt.jar 에 소속된 패키지다.
그래서 AIX jre(1.4) 의 /lib 를 뒤졌더니, rt.jar 란 이름을 가진 jar 가 없더라. 알고 보니 아래와 같은 사정이.
'원래 예전버젼의 AIX 용 jre 에는 rt.jar 라 하여 SUN jdk 와 동일한 파일이 존재 했었다.
그러다가 1.4 이후의 IBM jre, 에서는 그게 몇몇 파일로 나누어 졌는데 그내용은 아래와 같다.'
| core.jar | which contains the majority of the class libraries, including the system, IO, and net class libraries |
| graphics.jar | which contains the awt and swing class libraries |
| security.jar | which contains the security framework code. For maintenance reasons, security.jar has been split up into smaller JAR files from v1.4.2 onwards. |
| xml.jar | which contains the xml and html class libraries |
그중 이번에 사고를 터트린 jaxp.DocumentBuilderFactoryImpl 은 xml.jar 에 정의 되어 있는것을 확인했다.
그리고 패키지 내용을 좀더 확인 해보니, SUN의 rt.jar 내에 있는 org.apache.crimson 이하의 패키지들이 IMB의 xml.jar 에서는 org.apache.xerces 패키지 이하로 들어가 있는 것도 확인했다.
rt.jar
xml.jar
완벽 연구되어 '향후 AIX 용 APP은 문제 없어!' 까지는 아니더라도, 참고하여 대응정도는 할수 있을것 같다. 시간나면 각각의 jar가 SUN 의 jar 와 어떤 식으로 대응 되는지 좀더 자세한 메모가 필요하겠다.
※ IBM 의 jdk 관련 사이트에서 명확하게 확인한 것이 아니고, 개발새발 하는 영어라 잘못 이해 한것도 있으리라 생각 된다. 참고 자료 정도록 생각 하자. 더 확실해 질때 가지.
※ 확인된 jdk 버젼은 SUN 1.4(j2sdk1.4.2_13) IBM 1.4 의 경우다 버젼에 따라. 다를 수 있으니 조심하자.
Trackback 0 And
Comment 0
Client가 Oracle DBMS 의 인스턴스에 접속하기 위해서는, DBMS 가 구동된 서버의 IP, 접속 프로토콜, PORT 등의 등보가 필요하다.
그런데,
Oracle 의 인스턴스는 보통 여러개가 생성될수 있고 그 인스턴스들에 접속하기 위한 접속 정보역시 각각 관리된다. 그러므로 인스턴스들은 서로 구별되기 위한 '뭔가'가 필요하다.
그 '뭔가'가 바로 'SID'
현재 접속한 인스턴스의 'SID'는 아래와 같이 쿼리로 확인 할 수도 있고
select name from v$database;
LISTENER.ORA 파일서 확인 할 수도 있다.
Trackback 0 And
Comment 0
표면상으로 같은 동작을 하는 것처럼 보이는 두 동작(좀더 자세히 말하면 DELETE 의 경우 WHERE절이 없는 경우)이 사실 기본적으로 큰 차이점이 있다한다.
종종..
'그럼 새 데이터 넣기전에 기존 테이블 은 TRUNCATE 하도록 합시다' 하는 의견이 나올때 별생각 없이 'ㅇㅋ 알겠심' 하고 넘어 갔었다. 물론 별다른 생각도 없었다.
갑자기 문득 궁금해 지는것이, 나도 이제 내 IT 바닥 '짬밥'에 대한 책임감 이란게 슬슬 생기기 시작 하나보다.
그럼 비교를 시작 해보자.
기본적으로 대상 테이블에대한 모든 값을 삭제한다는 동일한 기능을 가진다.
하지만 TRUNCATE 와 DELETE 는 각각 'DDL' 과 'DML'로 다른 종류의 Query 다.
그에 따라 아래와 같은 차이를 가진다.
| 종류 | 차이점 | |
| TRUNCATE | DDL | 자동 커밋이 발생한다. ROLLBACK 명령으로 상태를 되돌릴수 없다. 상대적으로 실행속도가 빠르다. |
| DELETE | DML | ROLLBACK 명령으로 상태를 되돌릴수 있다. 삭제시 트랜잭션 로그에 기록이 함께 수행되므로 상대적으로 느리다. |
위와 같이 TRUNCATE 는 DELETE 에 비해 상대적으로 빠른 수행속도를 보여주나, 되돌릴수 없음을 상기하고 조심 또
조심해 써야 하겠다.
Trackback 0 And
Comment 0
Prev
