반응형
제품 : JDBC

작성날짜 :

FILE을 CLOB에 INSERT하고, 반대로 컬럼을 읽어 FILE로 WRITE하는 JDBC PROGRAM 예제 (JDBC 8.1 이상)



PURPOSE

text file을 읽어서 CLOB column 에 저장하는 방법과, CLOB column의 데이타를
읽어서 file로 write하는 방법을 예제를 통해서 살펴본다.


Explanation



oracle.sql package에서 제공하는 CLOB class를 이용한다.
file의 내용을 읽어 CLOB type에 저장할 때는 CLOB.getCharacterOutputStream을
이용하고, 반대로 file에 write를 위해 CLOB type을 읽을 때는
clob.getCharacterStream() 를 이용한다.

Oracle JDBC driver 8.1.x 이상 version의 classes12.zip file이 CLASSPATH에
지정되어 있어야 한다. JDK는 1.2 이상을 사용한다.

[참고] 화일을 이용하지 않고 직접 text를 CLOB에 입력하고, 입력된 CLOB
데이타를 화면에 display하기 위해서는 아래 bulletin을 참고한다.
<Bulletin No: 19360>: Subject: ORACLE.SQL.CLOB CLASS를 이용하여
4000 BYTES이상의 CLOB TEXT 데이타를 저장하고, 조회하는 예제

Example


1. 테이블의 생성과 데이타 입력

미리 다음 작업이 수행되어 있어야 하며, 이 작업도 java application내에
statement.execute를 통해 포함시킬 수 있다.

sqlplus scott/tiger
SQL> create table test_clob(id number, c clob);
SQL> insert into test_clob values (1, empty_clob());

2. ClobFile.java

다음 내용을 ClobFile.java라는 이름으로 생성한 후,

os>javac ClobFile.java
os>java ClobFile
후 out.txt file내용을 확인하고, scott.TEST_CLOB table의 데이타도 조회하여
수해이 잘 되었는지 확인한다.

import java.sql.*;
import java.io.*;
import java.util.*;
import oracle.jdbc.driver.*;

import oracle.sql.*;

public class ClobFile {

public static void main (String args []) throws Exception {

try {
Connection conn;

DriverManager.registerDriver( new oracle.jdbc.driver.OracleDriver() );
conn = DriverManager.getConnection( "jdbc:oracle:thin:@krint-5:1521:ORA920"

, "scott","tiger" );

conn.setAutoCommit (false);

CLOB clob = null;

Statement stmt = conn.createStatement ();

String cmd = "select * from test_clob for update";
ResultSet rset = stmt.executeQuery(cmd);
while (rset.next())
clob = ((OracleResultSet)rset).getCLOB(2);

// 아랫부분에 file로 부터 데이타를 읽어 CLOB column에 저장하는
// readFromFile()이 작성되어 있다.

readFromFile(clob);
stmt.execute("commit");

rset = stmt.executeQuery ("select * from test_clob where id=1");

if (rset.next ())
{
clob = ((OracleResultSet)rset).getCLOB(2);
String st = rset.getString(2);

if (clob != null)
System.out.println ("clob length = "+clob.length ());
}

// 아랫부분의 CLOB 컬럼의 데이타를 읽어 다시 다른 file로 write하는
// writeToFile()을 호출한다.

writeToFile(clob);
}

catch (SQLException sqle) {
System.out.println("SQL Exception occured: " + sqle.getMessage());
sqle.printStackTrace();
}

catch(FileNotFoundException e) {
System.out.println("File Not Found");
}

catch (IOException ioe) {
System.out.println("IO Exception" + ioe.getMessage());
}
}

//


// test.txt file을 읽어 test_clob.c column에 저장한다.

static void readFromFile (CLOB clob) throws Exception {
File file = new File("/home/ora920/eykim/test.txt");
FileReader in = new FileReader(file);
Writer out = clob.getCharacterOutputStream();

int chunk = clob.getChunkSize();
System.out.print("The chunk size is " + chunk);
char[] buffer = new char[chunk];
int length;

while ((length = in.read(buffer,0,chunk)) != -1)
out.write(buffer, 0, length);

in.close();
out.close();
}

//------------------------------------------------------------------
// test.clob.c column의 데이타를 읽어 out.txt file로 write한다.

static void writeToFile (CLOB clob) throws Exception {
int chunk = clob.getChunkSize();

int length;
char[] buffer = new char[chunk];
FileWriter outFile = null;
outFile = new FileWriter("/home/ora920/eykim/out.txt");
Reader instream = clob.getCharacterStream();

while ((length = instream.read(buffer)) != -1) {
outFile.write(buffer, 0, length);
}

instream.close();
outFile.close();
}

}


Reference Documents


SCR #998


반응형
반응형

출처 : http://logonjava.blogspot.com/2010/04/heap-dump-perm-area-memory-leak.html


Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다.

이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다.

개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다.
관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만...

oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;;

perm gen 과 class leak
Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다.
lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다.

HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다.
메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다.

(class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객체로 타입명 뒤에 .class 라는 literal을 붙임으로써 지칭할 수 있다. 예를 들어 자바 코드에서 String.class 라는 객체는 java.lang.String 이라는 클래스의 타입을 지칭하는 객체이다.)

memory leak이란 보통 reclaim되어야 할 memory space가 reclaim되지 못하고 있는 상황을 뜻하는데 Java와 같이 garbage collector 기능을 내장한 VM에서는 주로 코드 오류로 인해 gc 대상이 되는 객체를 불필요하게 reference(자바에서는 weak reference나 soft reference와 구분하여 strong reference)하는 gc 대상이 아닌 객체들이 존재하기 때문에 발생한다.

perm area 에 위치하는 class 객체들은 classloader에 의해 load 되기 때문에 이 class 객체들이 unload되는 유일한 방법은 classloader가 unload 즉, gc 되는 것이다.

보통 Java VM이 로드될 때 사용되는 classloader들(runtime에 필요한 클래스를 주로 로드하는 system classloader와 classpath에 설정된 클래스들을 로드하는 application classloader 등)은 JVM이 종료할 때까지 gc되지 않기 때문에 여기에서는 관심의 대상이 아니고, 주로 application이 dynamic하게 코드 상에서 만드는 classloader들이 관심의 대상이 된다.

즉, 다시 말해서 "gc되어야 하는 classloader 객체가 어떤 다른 strong object 에 의해 참조되는 것을 찾는 것이 오늘의 주제"이다.

OutOfMemoryError와 heap dump
heap dump 분석은 Java에서 OutOfMemoryError(이하 OOM)가 발생할 경우 원인을 찾기 위해 많이 사용된다.
OOM 시 heap dump를 자동으로 생성하는 HotSpot JVM 옵션이 있는데 이에 관해서는 앞의 다른 blog를 참고하기 바란다.

OOM은 주로 세 가지 경우에 발생한다. 하나는 전체 heap memory 부족, 또하나는 permanent area 부족, 나머지 하나는 native thread를 더 이상 생성할 수 없을 경우이다.

전체 heap memory 부족은 너무 많은 객체를 만들거나 strong reference에 의해 객체 일부가 reclaim 되지 않아서 발생하게 된다. perm area 부족은 앞과 동일한 이유이겠지만 해당 객체가 class 객체인 경우이고 전체 heap 영역 중 perm 영역이 분리되어 있기 때문에 다르게 발생하는 것이다. thread를 생성 못하는 이유는 OS 환경과 상관이 있을 테고, 또 코드 수준에서 thread를 지나치게 많이 만들거나 또 thread 종료가 제대로 안되어 leak이 발생한 때문일 것이다.

세 가지 중 어느 원인으로 OOM이 발생했는지에 대해선 OOM 에러의 메시지를 보면 쉽게 알수 있다.

heap dump 분석에 필요한 소프트웨어
heap dump 분석을 위해 사용하는 소프트웨어는 다음과 같다.
먼저 heap dump 분석 프로그램. HP에서 제공하는 jmeter 가 있고, IBM에서 제공하는 HeapAnalyzer, SAP에서 만들었다가 지금은 eclipse에 donate된 MemoryAnalyzer 등이 있다.

다들 한번씩 try는 해봤지만 지금은 swing 기반으로 된 순수 자바 프로그램인 IBM HeapAnalyzer를 쓴다.
jmeter는 예쁘게 생겼지만 지원하는 heap dump 포맷이 제약이 있었고, SAP MemoryAnalyzer는 적은 메모리로 큰 dump 파일을 읽어들일 수 있긴 하지만, 제공해주는 정보들을 이해하기 좀 어려웠다.
그러다보니 IBM HeapAnalyzer에 익숙해져버렸다.

또, 하나 많이 사용하는 것은 X 서버이다. PC 환경에서 heap analyzer를 돌리기엔 heap dump 파일이 너무 커서 메모리를 많이 사용하기 때문에 대용량 heap을 사용할 수 있는 64비트 JVM 환경(32비트 JVM에서는 max heap size를 1.4기가 정도밖에 줄 수 없다. 정확한 최대값은 모르겠음)에서 heap analyzer를 실행해야 했는데 그러다보니 PC용 X 서버가 필요했다.

요즘 사용하는 PC용 X 서버는 free open source인 cygwin-x 이다. 큰 문제 없이 쓸 수 있다.



HeapAnalyzer 실행
요즘 개발자들은 X 환경을 이해 못하는 경우가 많아서 간단하게 PC용 X 서버에서 원격지의 heap analyzer를 어떻게 실행하는지 절차를 적어본다. (예전에 motif application 개발을 잠깐 했었던 추억이 있음)

유닉스에서 주로 사용되는 윈도우 시스템인 X-Window 시스템은 서버/클라이언트 구조로 되어 있으며 X 서버는 display를 제공하는 쪽을 뜻하고, 실제 애플리케이션 프로세스가 실행되는 쪽이 X 클라이언트가 된다.

1. X 서버인 cygwin-x를 PC에서 실행하고 xterm 프로그램을 하나 실행시킨다.

2. xterm의 shell prompt 에서 "xhost +" 명령을 실행한다. xhost는 X 서버에 접속할 수 있는 X 클라이언트 호스트들에 대한 접근 제어를 하는 명령이다. cygwin-x가 PC에서 실행되고 원격지 유닉스 서버에서 heap analyzer를 띄울 것이므로 PC가 X 서버이고 유닉스 서버가 X 클라이언트 호스트이다. xhost + 다음에 호스트 명을 주지 않으면 모든 호스트에 대해서 allow한다는 뜻이다.
다음과 같이 불평할 것이다.

[mypc]/home/yoonforh 504> xhost +
access control disabled, clients can connect from any host

3. 해당 유닉스 서버로 telnet 등을 통해 접근한다.
해당 유닉스 서버의 셸에서 DISPLAY 환경 변수를 cygwin-x가 실행된 PC로 지정해야 한다.
예를 들면 ksh이나 bash에서 다음과 같이 지정한다.

export DISPLAY=<PC IP 주소>:0

보통의 X용 appliation은 실행시 -display 옵션을 통해서 지정할 수도 있다. DISPLAY 환경변수 값은 ip 주소와 display screen 번호로 구성된다.

보통 기본값인 0 혹은 0.0을 screen number로 사용한다. 윈도우 시스템 위에 실행되는 window manager 프로그램에 따라 CDE나 gnome-desktop, mwm, twm 등은 여러 개의 screen을 가지므로 screen number를 0이 아닌 다른 값으로 지정할 수도 있다. 사실 대부분의 X용 윈도우 매니저들은 multi screen을 지원한다.
사족이 길어졌다. 그냥 0번 스크린을 지정한다. ㅠ_ㅠ

4. DISPLAY가 지정된 환경에서 heap analyzer를 실행한다.
해당 셸에서 다음과 같이 heap analyzer를 실행한다. 현재 사용하고 있는 버전은 3.7이다.

jdk 5이상 가능

jdk 6이상.


java -Xmx5G -jar ha37.jar

큰 heap dump 파일을 분석할 때에는 메모리가 많이 사용되므로 heap 최대값을 5G로 줬다. dump 파일 크기에 따라 더 줘야 할 경우도 있을 것이다. 앞에서 얘기했듯이 이 JVM이 64비트인 경우에 주로 지원된다. OS나 JVM 버전, 비트 수마다 지원하는 최대 heap 크기가 다르므로 이 부분은 알아서들 체크하기 바란다.

사족이 길었지만 이 application을 remote에서 띄워보려고 했다. 매번 연구원들에게 일일이 이런 것 가이드하기 싫어서 교육용으로 부연해보았다. cygwin-x 위에 뜬 heap analyzer 아마도 상당히 촌스럽다고 느낄 것이다. 뭐, 잘생겼다고 일 잘하는 건 아니다.

5. heap dump 파일을 읽어들인다.
보통 HotSpot JVM에서 binary format으로 heap dump를 남기게 하면 heap analyzer는 "HPROF binary"라는 포맷으로 읽어들인다.
perm area 부족으로 인한 OOM인 경우는 전체 heap 부족으로 인한 OOM인 경우보다는 heap size가 작으므로 dump 파일도 상대적으로 작다. (이것도 다행이라고 생각하면 되려나 ㅎㅎ)

dump 파일이 클수록 읽는 데 시간이 많이 걸리므로 open 시켜 놓고 다른 일을 하면 되겠다. 어차피 프로세싱은 원격지 서버에서 일어나는 것이니 PC에 몹쓸 짓은 안한다.

Object Reference 관계와 ClassLoader 간 계층 관계
이제 분석할 준비가 완료되었다. 몇 가지 필요한 사전 지식에 대해 언급해본다.

ClassLoader는 계층 구조를 가진다. 이 계층 구조는 ClassLoader를 생성할 때 반드시 부모 ClassLoader를 지정하도록 되어 있는데, 기본적인 자바의 class 정의 검색 방식은 부모 ClassLoader에 정의된 class 정의를 우선으로 찾고, 그 다음에 자식 ClassLoader에 정의된 class 정의를 찾는 구조이다.

자바의 각 ClassLoader들은 내부적으로 parent 라는 멤버 필드를 가지고 있고, 이 값이 부모 클래스로더 객체가 된다.
(classloader들의 parent/chlid 관계는 class inheritance의 parent class, child class와는 아무 상관이 없다.)

Object Reference 관계는 객체 간의 참조 구조를 나타내며 directed graph 형태이다. 즉, 참조자(Referencer)를 시작점으로 피참조자(Referencee)를 끝점으로 하나의 화살표가 그려지는 단방향 그래프 형태라고 생각할 수 있다.

표준적인 용어인지는 모르겠지만, HeapAnalyzer에서는 참조자를 parent, 피참조자를 child로 표현하고 있다. 그리고, parent가 없이 strong object인 경우를 root 라고 표현하고 있다.

즉, 단방향 그래프로 이루어진 forest 형태이지만 이것을 root node가 여러 개인 tree인 것으로 표현하고 있다. 생각해보면 root node들 위에 공통된 가상의 parent node 하나가 있다고 가정하면 하나의 tree로 볼 수 있다. 이렇게 보면 parent/child 용어는 적합하다고도 볼 수 있다. (엄밀하게 보면 상호 참조나 순환 참조가 가능하기 때문에 forest나 tree라고 볼 수 없다. 하지만, 여기에서 얘기하는 parent/child 관계를 적용하는 데는 큰 무리가 없으므로 child가 parent로도 되는 경우나 descendant가 ancestor의 parent가 되는 경우가 존재한다는 것을 예외로 간주하고 rough하게 metaphor를 적용해보자.)

이제 ClassLoader 간 parent/child 관계가 Object Reference 관계에서 어떤 관계를 가지는지 생각해보자. 이게 아마 이 논의의 핵심일 것이다.

Child ClassLoader 객체는 멤버 필드로 parent를 가지고 있으며 이 parent 필드의 값이 Parent ClassLoader 객체이다.
즉, Object Reference 관계로 보면 child classloader 객체가 parent란 필드를 통하여 parent classloader를 reference하고 있다.

다시 말하면 object reference 관계에서는 child classloader 가 referencer(parent), parent classloader가 referencee(child)로 되어 parent/child 관계가 뒤바뀐다.

용어적인 유사성 때문에 혼란이 오는 것이며 서로 관련없는 관계이지만, 결과적으로는 "일반적으로 classloader 객체 간 parent/child 관계는 객체 참조간 parent/child 관계와 반대가 된다"고 생각해도 되겠다.

분석 예
이제 실 예를 들어 perm leak을 찾아보자. 사실 perm leak 이 발생하려면 ClassLoader를 동적으로 만들어 사용하는 프로그램에서 가능하기 때문에 일반적인 application에서는 이런 경우가 많지 않다. 보통은 그냥 클래스를 많이 사용하는 경우이므로 JVM 옵션으로 perm area 영역을 늘려주면 된다.

하지만, plugin 과 같은 동적 프로그램 기능을 가지고 있는 application에서는 plugin을 위한 ClassLoader를 만들어 사용하기 때문에 이러한 경우가 종종 발생한다.

먼저 heap dump 파일을 HeapAnalyzer로 연 다음 "Analysis/Search Name" 기능을 사용하여 의심이 가는 클래스로더 객체를 찾는다. 클래스 명으로 찾을 수 있는데 dump 상에는 separator가 '.'이 아니라 '/'인 점을 주의하여 찾는다.


검색 결과를 보면 해당하는 타입의 객체와 클래스 객체가 나타난다. 아래 그림에서 클래스로더 객체는 12개가 존재한다. (13개 중 한 개는 클래스로더 타입을 나타내는 class 객체)


위 그림에서 보이듯이 각 클래스로더 객체를 선택하여 오른쪽 마우스 버튼(두번째 마우스 버튼)을 클릭하면 팝업 메뉴가 보이며 이를 통해 해당 객체의 parent 객체들이나 child 객체들을 추적할 수 있다.

클래스로더 객체를 참조하고 있는 객체 즉, object reference 관계에서 parent에 있는 객체들이 클래스로더 객체의 가비지 컬렉션을 막고 있는 상황을 찾아야 하므로, 계속해서 "List parents" 기능을 사용하여 object reference tree를 거슬러 올라가보면 문제가 되는 참조자 객체를 찾을 수 있을 것이다.

경우에 따라서는 parent 객체들이 sun/reflect/DelegatingClassLoader, java/security/ProtectionDomain, java/lang/Package 등만 나타나는 경우가 있는데 이런 객체들은 일시적인 참조이며, 이 경우는 garbage collection되기를 기다리고 있는 경우이기 때문에 leak이 아니다.

각 객체별로 parent를 추적해보면 알 수 있지만, ProtectionDomain 객체와 Package 객체는 ClassLoader 와 상호참조되는 객체들이며 다른 strong reference에 의해 연결되지 않으며 DelegatingClassLoader는 HotSpot JVM 에서 reflection을 사용하여 dynamic proxy 객체를 만들 때마다 일시적으로 사용되는 클래스로더이다.

object reference 상의 parent 추적은 여러 depth에 걸쳐 일어날 것이며 해당 클래스의 소스 코드를 알고 있다면 쉽게 연결하여 이해할 수 있을 것이다.


object reference graph 추적은 perm leak이든 일반적인 memory leak이든 동일하게 사용할 수 있다. 다만 여기에서는 classloader 객체가 leak이 되는 경우에 perm area problem이 발생한다는 것을 중심으로 설명하였다.

누구에게든 이 잡다한 내용이 작은 도움이 되길 바라면서...


출처 : http://logonjava.blogspot.com/2010/04/heap-dump-perm-area-memory-leak.html
반응형
반응형

The Zip format is also used in the JAR (Java ARchive) file format, which is a way to collect a group of files into a single compressed file, just like Zip. However, like everything else in Java, JAR files are cross-platform, so you don’t need to worry about platform issues. You can also include audio and image files as well as class files.

JAR files are particularly helpful when you deal with the Internet. Before JAR files, your Web browser would have to make repeated requests of a Web server in order to download all of the files that make up an applet. In addition, each of these files was uncompressed. By combining all of the files for a particular applet into a single JAR file, only one server request is necessary and the transfer is faster because of compression. And each entry in a JAR file can be digitally signed for security (see Chapter 14 for an example of signing).

A JAR file consists of a single file containing a collection of zipped files along with a “manifest” that describes them. (You can create your own manifest file; otherwise, the jar program will do it for you.) You can find out more about JAR manifests in the JDK documentation.

The jar utility that comes with Sun’s JDK automatically compresses the files of your choice. You invoke it on the command line:

jar [options] destination [manifest] inputfile(s)


The options are simply a collection of letters (no hyphen or any other indicator is necessary). Unix/Linux users will note the similarity to the tar options. These are:

c

Creates a new or empty archive.

t

Lists the table of contents.

x

Extracts all files.

x file

Extracts the named file.

f

Says: “I’m going to give you the name of the file.” If you don’t use this, jar assumes that its input will come from standard input, or, if it is creating a file, its output will go to standard output.

m

Says that the first argument will be the name of the user-created manifest file.

v

Generates verbose output describing what jar is doing.

0

Only store the files; doesn’t compress the files (use to create a JAR file that you can put in your classpath).

M

Don’t automatically create a manifest file.

If a subdirectory is included in the files to be put into the JAR file, that subdirectory is automatically added, including all of its subdirectories, etc. Path information is also preserved.

Here are some typical ways to invoke jar:

jar cf myJarFile.jar *.class


This creates a JAR file called myJarFile.jar that contains all of the class files in the current directory, along with an automatically generated manifest file.

jar cmf myJarFile.jar myManifestFile.mf *.class


Like the previous example, but adding a user-created manifest file called myManifestFile.mf.

jar tf myJarFile.jar


Produces a table of contents of the files in myJarFile.jar.

jar tvf myJarFile.jar


Adds the “verbose” flag to give more detailed information about the files in myJarFile.jar.

jar cvf myApp.jar audio classes image


Assuming audio, classes, and image are subdirectories, this combines all of the subdirectories into the file myApp.jar. The “verbose” flag is also included to give extra feedback while the jar program is working.

If you create a JAR file using the 0 (zero) option, that file can be placed in your CLASSPATH:

CLASSPATH="lib1.jar;lib2.jar;"


Then Java can search lib1.jar and lib2.jar for class files.

The jar tool isn’t as useful as a zip utility. For example, you can’t add or update files to an existing JAR file; you can create JAR files only from scratch. Also, you can’t move files into a JAR file, erasing them as they are moved. However, a JAR file created on one platform will be transparently readable by the jar tool on any other platform (a problem that sometimes plagues zip utilities).

As you will see in Chapter 14, JAR files are also used to package JavaBeans.

출처 : http://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ314_034.htm

반응형
반응형

Multifile storage with Zip

The library that supports the Zip format is much more extensive. With it you can easily store multiple files, and there’s even a separate class to make the process of reading a Zip file easy. The library uses the standard Zip format so that it works seamlessly with all the tools currently downloadable on the Internet. The following example has the same form as the previous example, but it handles as many command-line arguments as you want. In addition, it shows the use of the Checksum classes to calculate and verify the checksum for the file. There are two Checksum types: Adler32 (which is faster) and CRC32 (which is slower but slightly more accurate).

//: c12:ZipCompress.java
// Uses Zip compression to compress any
// number of files given on the command line.
// {Args: ZipCompress.java}
// {Clean: test.zip}
import com.bruceeckel.simpletest.*;
import java.io.*;
import java.util.*;
import java.util.zip.*;

public class ZipCompress {
  private static Test monitor = new Test();
  // Throw exceptions to console:
  public static void main(String[] args)
  throws IOException {
    FileOutputStream f = new FileOutputStream("test.zip");
    CheckedOutputStream csum =
      new CheckedOutputStream(f, new Adler32());
     ZipOutputStream zos = new ZipOutputStream(csum);
     BufferedOutputStream out =
      new BufferedOutputStream(zos);
    zos.setComment("A test of Java Zipping");
    // No corresponding getComment(), though.
    for(int i = 0; i < args.length; i++) {
      System.out.println("Writing file " + args[i]);
      BufferedReader in =
        new BufferedReader(new FileReader(args[i]));
      zos.putNextEntry(new ZipEntry(args[i]));
      int c;
      while((c = in.read()) != -1)
        out.write(c);
      in.close();
    }
    out.close();
    // Checksum valid only after the file has been closed!
    System.out.println("Checksum: " +
      csum.getChecksum().getValue());
    // Now extract the files:
    System.out.println("Reading file");
    FileInputStream fi = new FileInputStream("test.zip");
    CheckedInputStream csumi =
      new CheckedInputStream(fi, new Adler32());
    ZipInputStream in2 = new ZipInputStream(csumi);
    BufferedInputStream bis = new BufferedInputStream(in2);
    ZipEntry ze;
    while((ze = in2.getNextEntry()) != null) {
      System.out.println("Reading file " + ze);
      int x;
      while((x = bis.read()) != -1)
        System.out.write(x);
    }
    if(args.length == 1)
      monitor.expect(new String[] {
        "Writing file " + args[0],
        "%% Checksum: \\d+",
        "Reading file",
        "Reading file " + args[0]}, args[0]);
    System.out.println("Checksum: " +
      csumi.getChecksum().getValue());
    bis.close();
    // Alternative way to open and read zip files:
    ZipFile zf = new ZipFile("test.zip");
    Enumeration e = zf.entries();
    while(e.hasMoreElements()) {
      ZipEntry ze2 = (ZipEntry)e.nextElement();
      System.out.println("File: " + ze2);
      // ... and extract the data as before
    }
    if(args.length == 1)
      monitor.expect(new String[] {
        "%% Checksum: \\d+",
        "File: " + args[0]
      });
  }
} ///:~


For each file to add to the archive, you must call putNextEntry( ) and pass it a ZipEntry object. The ZipEntry object contains an extensive interface that allows you to get and set all the data available on that particular entry in your Zip file: name, compressed and uncompressed sizes, date, CRC checksum, extra field data, comment, compression method, and whether it’s a directory entry. However, even though the Zip format has a way to set a password, this is not supported in Java’s Zip library. And although CheckedInputStream and CheckedOutputStream support both Adler32 and CRC32 checksums, the ZipEntry class supports only an interface for CRC. This is a restriction of the underlying Zip format, but it might limit you from using the faster Adler32.

To extract files, ZipInputStream has a getNextEntry( ) method that returns the next ZipEntry if there is one. As a more succinct alternative, you can read the file using a ZipFile object, which has a method entries( ) to return an Enumeration to the ZipEntries.

In order to read the checksum, you must somehow have access to the associated Checksum object. Here, a reference to the CheckedOutputStream and CheckedInputStream objects is retained, but you could also just hold onto a reference to the Checksum object.

A baffling method in Zip streams is setComment( ). As shown in ZipCompress.java, you can set a comment when you’re writing a file, but there’s no way to recover the comment in the ZipInputStream. Comments appear to be supported fully on an entry-by-entry basis only via ZipEntry.

Of course, you are not limited to files when using the GZIP or Zip libraries—you can compress anything, including data to be sent through a network connection.

출처 : http://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ314_033.htm

반응형

'Language > JAVA' 카테고리의 다른 글

Heap Dump 분석을 통한 Perm Area Memory Leak 원인 진단  (0) 2010.12.14
Java ARchives (JAR)  (0) 2010.11.17
자바 간단한 GZIP 압축 예제  (0) 2010.11.17
자바 파일 압축  (0) 2010.11.17
JAVA File Locking(자바 파일 잠금)  (0) 2010.11.17
반응형

Simple compression with GZIP

The GZIP interface is simple and thus is probably more appropriate when you have a single stream of data that you want to compress (rather than a container of dissimilar pieces of data). Here’s an example that compresses a single file:

//: c12:GZIPcompress.java
// {Args: GZIPcompress.java}
// {Clean: test.gz}
import com.bruceeckel.simpletest.*;
import java.io.*;
import java.util.zip.*;

public class GZIPcompress {
  private static Test monitor = new Test();
  // Throw exceptions to console:
  public static void main(String[] args)
  throws IOException {
    if(args.length == 0) {
      System.out.println(
        "Usage: \nGZIPcompress file\n" +
        "\tUses GZIP compression to compress " +
        "the file to test.gz");
      System.exit(1);
    }
    BufferedReader in = new BufferedReader(
      new FileReader(args[0]));
    BufferedOutputStream out = new BufferedOutputStream(
      new GZIPOutputStream(
        new FileOutputStream("test.gz")));
    System.out.println("Writing file");
    int c;
    while((c = in.read()) != -1)
      out.write(c);
    in.close();
    out.close();
    System.out.println("Reading file");
    BufferedReader in2 = new BufferedReader(
      new InputStreamReader(new GZIPInputStream(
        new FileInputStream("test.gz"))));
    String s;
    while((s = in2.readLine()) != null)
      System.out.println(s);
    monitor.expect(new String[] {
      "Writing file",
      "Reading file"
    }, args[0]);
  }
} ///:~


The use of the compression classes is straightforward; you simply wrap your output stream in a GZIPOutputStream or ZipOutputStream, and your input stream in a GZIPInputStream or ZipInputStream. All else is ordinary I/O reading and writing. This is an example of mixing the char-oriented streams with the byte-oriented streams; in uses the Reader classes, whereas GZIPOutputStream’s constructor can accept only an OutputStream object, not a Writer object. When the file is opened, the GZIPInputStream is converted to a Reader.

출처 : http://www.linuxtopia.org/

반응형
반응형

Compression

The Java I/O library contains classes to support reading and writing streams in a compressed format. These are wrapped around existing I/O classes to provide compression functionality.

These classes are not derived from the Reader and Writer classes, but instead are part of the InputStream and OutputStream hierarchies. This is because the compression library works with bytes, not characters. However, you might sometimes be forced to mix the two types of streams. (Remember that you can use InputStreamReader and OutputStreamWriter to provide easy conversion between one type and another.)

 

Compression class

Function

CheckedInputStream

GetCheckSum( ) produces checksum for any InputStream (not just decompression).

CheckedOutputStream

GetCheckSum( ) produces checksum for any OutputStream (not just compression).

DeflaterOutputStream

Base class for compression classes.

ZipOutputStream

A DeflaterOutputStream that compresses data into the Zip file format.

GZIPOutputStream

A DeflaterOutputStream that compresses data into the GZIP file format.

InflaterInputStream

Base class for decompression classes.

ZipInputStream

An InflaterInputStream that decompresses data that has been stored in the Zip file format.

GZIPInputStream

An InflaterInputStream that decompresses data that has been stored in the GZIP file format.


Although there are many compression algorithms, Zip and GZIP are possibly the most commonly used. Thus you can easily manipulate your compressed data with the many tools available for reading and writing these formats.

출처 : http://www.linuxtopia.org/

반응형
반응형

File locking

File locking, introduced in JDK 1.4, allows you to synchronize access to a file as a shared resource. However, the two threads that contend for the same file may be in different JVMs, or one may be a Java thread and the other some native thread in the operating system. The file locks are visible to other operating system processes because Java file locking maps directly to the native operating system locking facility.

Here is a simple example of file locking.

//: c12:FileLocking.java
// {Clean: file.txt}
import java.io.FileOutputStream;
import java.nio.channels.*;

public class FileLocking {
  public static void main(String[] args) throws Exception {
    FileOutputStream fos= new FileOutputStream("file.txt");
    FileLock fl = fos.getChannel().tryLock();
    if(fl != null) {
      System.out.println("Locked File");
      Thread.sleep(100);
      fl.release();
      System.out.println("Released Lock");
    }
    fos.close();
  }
} ///:~


You get a FileLock on the entire file by calling either tryLock( ) or lock( ) on a FileChannel. (SocketChannel, DatagramChannel, and ServerSocketChannel do not need locking since they are inherently single-process entities; you don’t generally share a network socket between two processes.) tryLock( ) is non-blocking. It tries to grab the lock, but if it cannot (when some other process already holds the same lock and it is not shared), it simply returns from the method call. lock( ) blocks until the lock is acquired, or the thread that invoked lock( ) is interrupted, or the channel on which the lock( ) method is called is closed. A lock is released using FileLock.release( ).

It is also possible to lock a part of the file by using

tryLock(long position, long size, boolean shared)


or

lock(long position, long size, boolean shared)


which locks the region (size - position). The third argument specifies whether this lock is shared.

Although the zero-argument locking methods adapt to changes in the size of a file, locks with a fixed size do not change if the file size changes. If a lock is acquired for a region from position to position+size and the file increases beyond position+size, then the section beyond position+size is not locked. The zero-argument locking methods lock the entire file, even if it grows.

Support for exclusive or shared locks must be provided by the underlying operating system. If the operating system does not support shared locks and a request is made for one, an exclusive lock is used instead. The type of lock (shared or exclusive) can be queried using FileLock.isShared( ).

Locking portions of a mapped file

As mentioned earlier, file mapping is typically used for very large files. One thing that you may need to do with such a large file is to lock portions of it so that other processes may modify unlocked parts of the file. This is something that happens, for example, with a database, so that it can be available to many users at once.

Here’s an example that has two threads, each of which locks a distinct portion of a file:

//: c12:LockingMappedFiles.java
// Locking portions of a mapped file.
// {RunByHand}
// {Clean: test.dat}
import java.io.*;
import java.nio.*;
import java.nio.channels.*;

public class LockingMappedFiles {
  static final int LENGTH = 0x8FFFFFF; // 128 Mb
  static FileChannel fc;
  public static void main(String[] args) throws Exception {
    fc = 
      new RandomAccessFile("test.dat", "rw").getChannel();
    MappedByteBuffer out = 
      fc.map(FileChannel.MapMode.READ_WRITE, 0, LENGTH);
    for(int i = 0; i < LENGTH; i++)
      out.put((byte)'x');
    new LockAndModify(out, 0, 0 + LENGTH/3);
    new LockAndModify(out, LENGTH/2, LENGTH/2 + LENGTH/4);
  }
  private static class LockAndModify extends Thread {
    private ByteBuffer buff;
    private int start, end;
    LockAndModify(ByteBuffer mbb, int start, int end) {
      this.start = start;
      this.end = end;
      mbb.limit(end);
      mbb.position(start);
      buff = mbb.slice();
      start();
    }    
    public void run() {
      try {
        // Exclusive lock with no overlap:
        FileLock fl = fc.lock(start, end, false);
        System.out.println("Locked: "+ start +" to "+ end);
        // Perform modification:
        while(buff.position() < buff.limit() - 1)
          buff.put((byte)(buff.get() + 1));
        fl.release();
        System.out.println("Released: "+start+" to "+ end);
      } catch(IOException e) {
        throw new RuntimeException(e);
      }
    }
  }
} ///:~


The LockAndModify thread class sets up the buffer region and creates a slice( ) to be modified, and in run( ), the lock is acquired on the file channel (you can’t acquire a lock on the buffer—only the channel). The call to lock( ) is very similar to acquiring a threading lock on an object—you now have a “critical section” with exclusive access to that portion of the file.

The locks are automatically released when the JVM exits, or the channel on which it was acquired is closed, but you can also explicitly call release( ) on the FileLock object, as shown here.

출처 : http://www.linuxtopia.org/

반응형
반응형

Memory-mapped files

Memory-mapped files allow you to create and modify files that are too big to bring into memory. With a memory-mapped file, you can pretend that the entire file is in memory and that you can access it by simply treating it as a very large array. This approach greatly simplifies the code you write in order to modify the file. Here’s a small example:

//: c12:LargeMappedFiles.java
// Creating a very large file using mapping.
// {RunByHand}
// {Clean: test.dat}
import java.io.*;
import java.nio.*;
import java.nio.channels.*;

public class LargeMappedFiles {
  static int length = 0x8FFFFFF; // 128 Mb
  public static void main(String[] args) throws Exception {
    MappedByteBuffer out = 
      new RandomAccessFile("test.dat", "rw").getChannel()
      .map(FileChannel.MapMode.READ_WRITE, 0, length);
    for(int i = 0; i < length; i++)
      out.put((byte)'x');
    System.out.println("Finished writing");
    for(int i = length/2; i < length/2 + 6; i++)
      System.out.print((char)out.get(i));
  }
} ///:~


To do both writing and reading, we start with a RandomAccessFile, get a channel for that file, and then call map( ) to produce a MappedByteBuffer, which is a particular kind of direct buffer. Note that you must specify the starting point and the length of the region that you want to map in the file; this means that you have the option to map smaller regions of a large file.

MappedByteBuffer is inherited from ByteBuffer, so it has all of ByteBuffer’s methods. Only the very simple uses of put( ) and get( ) are shown here, but you can also use things like asCharBuffer( ), etc.

The file created with the preceding program is 128 MB long, which is probably larger than the space your OS will allow. The file appears to be accessible all at once because only portions of it are brought into memory, and other parts are swapped out. This way a very large file (up to 2 GB) can easily be modified. Note that the file-mapping facilities of the underlying operating system are used to maximize performance.

Performance

Although the performance of “old” stream I/O has been improved by implementing it with nio, mapped file access tends to be dramatically faster. This program does a simple performance comparison:

//: c12:MappedIO.java
// {Clean: temp.tmp}
import java.io.*;
import java.nio.*;
import java.nio.channels.*;

public class MappedIO {
  private static int numOfInts = 4000000;
  private static int numOfUbuffInts = 200000;
  private abstract static class Tester {
    private String name;
    public Tester(String name) { this.name = name; }
    public long runTest() {
      System.out.print(name + ": ");
      try {
        long startTime = System.currentTimeMillis();
        test();
        long endTime = System.currentTimeMillis();
        return (endTime - startTime);
      } catch (IOException e) {
        throw new RuntimeException(e);
      }
    }
    public abstract void test() throws IOException;
  }
  private static Tester[] tests = { 
    new Tester("Stream Write") {
      public void test() throws IOException {
        DataOutputStream dos = new DataOutputStream(
          new BufferedOutputStream(
            new FileOutputStream(new File("temp.tmp"))));
        for(int i = 0; i < numOfInts; i++)
          dos.writeInt(i);
        dos.close();
      }
    }, 
    new Tester("Mapped Write") {
      public void test() throws IOException {
        FileChannel fc = 
          new RandomAccessFile("temp.tmp", "rw")
          .getChannel();
        IntBuffer ib = fc.map(
          FileChannel.MapMode.READ_WRITE, 0, fc.size())
          .asIntBuffer();
        for(int i = 0; i < numOfInts; i++)
          ib.put(i);
        fc.close();
      }
    }, 
    new Tester("Stream Read") {
      public void test() throws IOException {
        DataInputStream dis = new DataInputStream(
          new BufferedInputStream(
            new FileInputStream("temp.tmp")));
        for(int i = 0; i < numOfInts; i++)
          dis.readInt();
        dis.close();
      }
    }, 
    new Tester("Mapped Read") {
      public void test() throws IOException {
        FileChannel fc = new FileInputStream(
          new File("temp.tmp")).getChannel();
        IntBuffer ib = fc.map(
          FileChannel.MapMode.READ_ONLY, 0, fc.size())
          .asIntBuffer();
        while(ib.hasRemaining())
          ib.get();
        fc.close();
      }
    }, 
    new Tester("Stream Read/Write") {
      public void test() throws IOException {
        RandomAccessFile raf = new RandomAccessFile(
          new File("temp.tmp"), "rw");
        raf.writeInt(1);
        for(int i = 0; i < numOfUbuffInts; i++) {
          raf.seek(raf.length() - 4);
          raf.writeInt(raf.readInt());
        }
        raf.close();
      }
    }, 
    new Tester("Mapped Read/Write") {
      public void test() throws IOException {
        FileChannel fc = new RandomAccessFile(
          new File("temp.tmp"), "rw").getChannel();
        IntBuffer ib = fc.map(
          FileChannel.MapMode.READ_WRITE, 0, fc.size())
          .asIntBuffer();
        ib.put(0);
        for(int i = 1; i < numOfUbuffInts; i++)
          ib.put(ib.get(i - 1));
        fc.close();
      }
    }
  };
  public static void main(String[] args) {
    for(int i = 0; i < tests.length; i++)
      System.out.println(tests[i].runTest());
  }
} ///:~


As seen in earlier examples in this book, runTest( ) is the Template Method that provides the testing framework for various implementations of test( ) defined in anonymous inner subclasses. Each of these subclasses perform one kind of test, so the test( ) methods also give you a prototype for performing the various I/O activities.

Although a mapped write would seem to use a FileOutputStream, all output in file mapping must use a RandomAccessFile, just as read/write does in the preceding code.

Here’s the output from one run:

Stream Write: 1719
Mapped Write: 359
Stream Read: 750
Mapped Read: 125
Stream Read/Write: 5188
Mapped Read/Write: 16


Note that the test( ) methods include the time for initialization of the various I/O objects, so even though the setup for mapped files can be expensive, the overall gain compared to stream I/O is significant.

출처 : http://www.linuxtopia.org/

반응형
반응형


Search_class.sh

#!/bin/ksh
#
############[ Useage ]############
if [ $# -lt 1 ]; then
        echo "Usage: $0 찾을Class명"
        exit 0
fi
 
for file in $(ls -1 *.jar)
do
        echo "[ $file ]"
        jar tvf $file | grep $1
done

 
반응형
반응형

1) import 시켜야할 API

① oracle.sql.BLOB

② oracle.sql.CLOB

③ oracle.jdbc.driver.OracleResultSet

2) CLOB

① DB에 CLOB 데이터형 쓰기

       // UPDATE 또는 INSERT 명령으로 DB 에 공간 확보
     String query = "UPDATE TABLE SET CLOB_DATA = EMPTY_CLOB() " ;
     stmt.executeUpdate(query);

     // 그런 다음 다시 요놈을 다시 SELECT
     query = "SELECT CLOB_DATA  FROM TABLE WHERE ~ " ;   

     stmt = dbConn.createStatement();
     rs = stmt.executeQuery(query);

     if(rs.next()) {
          CLOB clob = null;
          Writer writer = null;
          Reader src = null;
          char[] buffer = null;
          int read = 0;  

          clob = ((OracleResultSet)rs).getCLOB(1);        
          writer = clob.getCharacterOutputStream();

          // str -> DB에 넣을 내용
          src = new CharArrayReader(str.toCharArray());
          buffer = new char[1024];
          read = 0;
          while ( (read = src.read(buffer,0,1024)) != -1) {
               writer.write(buffer, 0, read); // write clob.
          }
          src.close();        
          writer.close();
     }

     dbConn.commit();
     dbConn.setAutoCommit(true);


 ② DB에서 CLOB 데이터형 읽기

      // SELECT
     String query = "SELECT CLOB_DATA  FROM TABLE WHERE ~ " ;   

     stmt = dbConn.createStatement();
     rs = stmt.executeQuery(query);

     if(rs.next()) {

          StringBuffer output = new StringBuffer();
          Reader input = rs.getCharacterStream("CLOB_DATA");
          char[] buffer = new char[1024];
          int byteRead = 0;
          while((byteRead=input.read(buffer,0,1024))!=-1){
               output.append(buffer,0,byteRead);
          }
         

          // contents -> CLOB 데이터가 저장될 String
          String contents = output.toString();


     }

     dbConn.commit();
     dbConn.setAutoCommit(true);


3) BLOB

① DB에 BLOB 데이터형 쓰기

      // UPDATE 또는 INSERT 명령으로 DB 에 공간 확보
     String query = "UPDATE TABLE SET BLOB_DATA = EMPTY_BLOB() " ;
     stmt.executeUpdate(query);

     // 그런 다음 다시 요놈을 다시 SELECT
     query = "SELECT BLOB_DATA  FROM TABLE WHERE ~ " ;   

     stmt = dbConn.createStatement();
     rs = stmt.executeQuery(query);

     if(rs.next()) {

          BLOB blob = null;
          BufferedOutputStream out = null;
          BufferedInputStream in = null;
          byte[] buf = null;
          int bytesRead= 0;  

          blob = ((OracleResultSet)rs).getBLOB(1);
          out = new BufferedOutputStream(blob.getBinaryOutputStream());

          // str -> DB에 넣을 내용
          in = new BufferedInputStream(new StringBufferInputStream(str));
          int nFileSize = (int)str.length();
          buf = new byte[nFileSize];
         
          while ((bytesRead = in.read(buf)) != -1){
               out.write(buf, 0, bytesRead);

          }

          in.close();
          out.close();
     }

     dbConn.commit();
     dbConn.setAutoCommit(true);


 ② DB에서 BLOB 데이터형 읽기

      // SELECT
     String query = "SELECT CLOB_DATA  FROM TABLE WHERE ~ " ;   

     stmt = dbConn.createStatement();
     rs = stmt.executeQuery(query);

     if(rs.next()) {

          BLOB blob = ((OracleResultSet)rs).getBLOB(1);

          BufferedInputStream in = new BufferedInputStream(blob.getBinaryStream());
          int nFileSize = (int)blob.length();
          byte[] buf = new byte [nFileSize];   
          int nReadSize = in.read(buf, 0, nFileSize);
          in.close();

           // contents -> BLOB 데이터가 저장될 String

          String contents = new String(buf);
     }

     dbConn.commit();
     dbConn.setAutoCommit(true);


출처 : http://lambert.egloos.com/3069062
반응형

+ Recent posts