반응형
자바 ARIA 사용하는 암호화 소스...
뭐 이젠 없어질 꺼지만...
나중이라도..
크크...
SSO 가격도 비싸고 -_-...
그걸 굳이 쓸 필요가 있을까 싶다...
반응형
분류 전체보기
- Cipher 암호화 소스 2012.05.15
- 무한 반복 BAT 파일 만들기 2012.05.14
- 웹 디버깅 문제점 찾기 2012.05.11
- Java 성능 모니터링에 대해 모르고 있던 5가지 사항, Part 1 2012.05.02
- 개발자의 실수를 줄여주는 java.sql.Connection 만들기(퍼옴) 2012.04.20
- 윈도우 hosts 파일 오류시 조치 방법 2012.04.12
- 엑셀 대용량 다운로드 가능하게 자바 만들기 2012.04.05
- 해커그룹 어노니머스, 해킹 전용 OS 공개 2012.03.16
- windows XP USB 설치본 만들기 2012.03.08
- Windows 7 Usb 설치 본 만들기... 2012.03.08
Cipher 암호화 소스
2012. 5. 15. 16:45
무한 반복 BAT 파일 만들기
2012. 5. 14. 10:01
반응형
후암...
Shell 과 같은 형태로 BAT를 만드는 것은 왜케 어렵나 -_-
참조 사이트 : http://mwultong.blogspot.com/2007/05/batch-file-infinity-loop.html
우선 local PC와 원격 서버와의 연결 정보(대용량 엑셀 다운로드 시)
확인하기 위해
주기적인 findstr 과 netstat를 통해 정보를 추출할 필요가 있다!
그런데.. 손가락 아퍼...
그래서 1초 단위로 Ctrl + C 누를 때까지 무한 반복하는 BAT 파일임...
@echo off |
반응형
'OS' 카테고리의 다른 글
| net 명령어 (0) | 2014.11.13 |
|---|---|
| 폴더 계정별 권한 부여하기 (0) | 2014.11.13 |
| CMD 창 모양 크기 색 변경하기 (2) | 2013.01.10 |
웹 디버깅 문제점 찾기
2012. 5. 11. 17:55
반응형
두개의 툴이 있다..
하나는 패스워드...
다른 하나는 다운로드
20120511_HTTP Analyzer v3.0.5 (Full Edition).zip
핀들러는
https 프로토콜도 검색 가능하다.
https 프로토콜 검색 방법 : http://blog.danggun.net/734
프록시 설정(웹 해킹시 사용할 때) : http://cafe.naver.com/webprogrammer2/108
다운로드 : http://www.fiddler2.com/Fiddler2/version.asp
Fiddler2Setup.exe반응형
'Windows > Internet' 카테고리의 다른 글
| Chrome 확장 기능 관련 (2) | 2019.05.15 |
|---|---|
| C Browser (씨 브라우저) 3.40 (0) | 2013.01.09 |
| wget 활용 - 헤더 정보보기 (0) | 2011.06.23 |
| (웹사이트 복원 오류) (웹사이트) [으]로 되돌아 갈 수 없었습니다. 라고 뜰 때 해결방법 (1) | 2010.11.26 |
| 한 PC에서 여러 버젼의 IE를 사용해 보자 ! (0) | 2010.11.09 |
Java 성능 모니터링에 대해 모르고 있던 5가지 사항, Part 1
2012. 5. 2. 13:24
반응형
Java 성능 모니터링에 대해 모르고 있던 5가지 사항, Part 1
JConsole과 VisualVM을 사용한 Java 성능 프로파일링
요약： 잘못된 코드(또는 잘못된 코드의 작성자)를 비난하는 것은 성능 병목 현상을 찾아내고 Java™ 애플리케이션의 속도를 향상시키는 데 아무런 도움이 되지 않으며 그 어느 것도 추측할 수 없습니다. 이 기사를 통해 Ted Neward는 Java 성능 모니터링 도구에 대한 관심을 촉구하고 있으며 먼저 Java 5의 내장 프로파일러인 JConsole을 사용하여 성능 데이터를 수집 및 분석하는 방법에 대한 5가지 팁을 소개합니다.
원문 게재일: 2010 년 6 월 29 일
번역 게재일: 2010 년 11 월 02 일
난이도: 초급
영어로: 보기
PDF: A4 and Letter (28KB | 7 pages)Get Adobe® Reader®
페이지뷰： 3707 회
의견： 0 (보기 | 의견 추가 - 로그인)
애플리케이션 성능이 나쁠 경우 많은 개발자는 공황 상태에 빠지고 만다. 그리고 이러한 성능 저하에는 합당한 이유가 있기 마련이다. Java 애플리케이션 병목 현상의 소스를 추적하는 작업은 역사적으로 매우 어려운 작업 중 하나이다. 왜냐하면 Java 가상 머신에 블랙박스 효과가 있을 뿐만 아니라 전통적으로 Java 플랫폼용 프로파일링 도구가 부족하기 때문이다.
하지만 Java 5에서 JConsole이 등장하면서 모든 것이 바뀌었다. JConsole은 명령행과 GUI 쉘에서 작동하는 내장 Java 성능 프로파일러이다. 이 프로파일러는 완벽하지는 않지만 지식이 풍부한 책임자가 성능 문제점을 지적할 때 적절하게 대응할 수 있는 방법을 제공할 뿐만 아니라 Papa Google에 문의하는 것보다 전체적으로 훨씬 더 좋은 결과를 제공한다.
5가지 사항 시리즈의 이 기사에서는 JConsole(또는 유사한 기능을 그래픽으로 제공하는 VisualVM)을 사용하여 Java 애플리케이션 성능을 모니터링하고 Java 코드의 병목 현상을 추적하는 데 사용할 수 있는 5가지 쉬운 방법을 설명한다.
많은 Java 개발자가 Java 5 이후로 프로파일러 도구가 JDK에 포함되어 있다는 사실을 모르고 있다. JConsole(또는 최근 Java 플랫폼 릴리스의 경우에는 VisualVM)은 Java 컴파일러처럼 쉽게 실행할 수 있는 내장 프로파일러이다. JDK가 PATH에 있는 명령 프롬프트에서 jconsole을 실행하거나 GUI 쉘에서 JDK 설치 디렉토리로 이동한 후 bin 폴더를 열고 jconsole을 두 번 클릭한다.
프로파일러 도구가 실행되면 실행 중인 Java의 버전과 동시에 실행 중인 다른 Java 프로그램의 수에 따라 연결할 프로세스의 URL을 묻는 대화 상자가 표시되거나 연결할 수많은 다른 로컬 Java 프로세스가 나열되며, 나열된 목록에 JConsole 프로세스 자체가 포함되기도 한다.
Java 5에서 Java 프로세스는 기본적으로 프로파일링되도록 설정되지 않는다. 시동 시에 명령행 인수 -Dcom.sun.management.jmxremote를 전달하면 Java 5 VM이 연결을 열게 되며 그러면 프로파일러가 연결을 찾을 수 있다. JConsole에서 프로세스가 선택되면 프로세스를 두 번 클릭하여 프로파일링을 시작할 수 있다.
프로파일러에는 고유한 오버헤드가 있으므로 이 오버헤드를 먼저 확인하는 것이 좋다. JConsole의 오버헤드를 가장 쉽게 확인하는 방법은 먼저 애플리케이션 자체를 실행한 다음 프로파일러 하에서 애플리케이션을 다시 실행하여 그 차이를 측정하는 것이다. (이 경우 애플리케이션이 너무 크거나 작아서도 안 된다. 필자는 주로 JDK에 포함된 SwingSet2 데모 애플리케이션을 사용한다.) 따라서 필자는 먼저 가비지 콜렉션 회수를 보기 위해 -verbose:gc를 사용하여 SwingSet2를 실행했다. 그런 다음 동일한 애플리케이션을 다시 실행한 후 JConsole 프로파일러를 연결했다. JConsole이 연결된 경우에는 GC 회수 스트림이 지속적으로 발생한 반면 그렇지 않은 경우에는 회수 스트림이 발생하지 않았다. 바로 이러한 차이가 프로파일러의 성능 오버헤드이다.
웹 애플리케이션 프로파일러는 소켓을 통한 프로파일링용 연결을 가정하므로 원격으로 실행 중인 애플리케이션을 모니터링/프로파일링하도록 JConsole(또는 JVMTI 기반 프로파일러)을 설정하는 간단한 구성만 수행하면 된다.
예를 들어, Tomcat이 "webserver"라는 시스템에서 실행 중이고 JVM에서 JMX를 사용하고 있고 포트 9004를 청취하고 있을 경우 JConsole(또는 기타 JMX 클라이언트)에서 JMX에 연결하려면 "service:jmx:rmi:///jndi/rmi://webserver:9004/jmxrmi"라는 JMX URL이 필요하다.
기본적으로 원격 데이터 센터에서 실행 중인 애플리케이션을 프로파일링하는 데 필요한 항목은 JMX URL이다. (JMX와 JConsole을 사용하여 원격 모니터링 및 관리를 수행하는 방법에 대한 자세한 정보는 참고자료를 참조한다.)
JConsole에는 다음 탭을 포함하여 통계 수집에 유용한 여러 가지 탭이 있다.
- Memory: JVM 가비지 콜렉터의 다양한 힙에 대한 활동을 추적한다.
- Threads: 대상 JVM의 현재 스레드 활동을 조사한다.
- Classes: 한 VM에 로드된 총 클래스 수를 검사한다.
이러한 탭(및 연관된 그래프)은 모두 Java 5 이상의 모든 VM이 JVM에 내장된 JMX 서버에 등록하는 JMX 오브젝트의 기능이다. 지정된 JVM에서 사용할 수 있는 전체 Bean 목록이 MBeans 탭에 나열되며, 해당 데이터를 보거나 이러한 조작을 실행하는 데 필요한 제한된 사용자 인터페이스와 일부 메타데이터가 함께 제공된다. (하지만 알림 등록은 JConsole 사용자 인터페이스의 범위에 해당되지 않는다.)
Tomcat 프로세스에서 OutOfMemoryError가 지속적으로 발생하고 있다고 가정하자. 어떻게 된 일인지 알아보기 위해 JConsole을 열고 Classes 탭을 클릭한 다음 클래스 수를 계속 살펴본다. 클래스 수가 지속적으로 올라가면 애플리케이션 서버 또는 코드의 어느 부분에선가ClassLoader 누수가 발생하고 있으며 머지 않아 PermGen 공간이 소진될 것이라고 간주할 수 있다. 문제점을 자세히 확인할 필요가 있는 경우에는 Memory 탭을 검사한다.
프로덕션 환경에서는 많은 작업이 빠르게 수행되기 때문에 애플리케이션 프로파일러에 할애할 수 있는 시간이 많지 않을 것이다. 대신 Java 환경의 모든 사항에 대한 스냅샷을 작성하여 저장한 후 나중에 살펴볼 수 있다. JConsole에서 이 작업을 수행할 수 있으며 VisualVM에서는 더 효과적으로 수행할 수 있다.
먼저 MBeans 탭으로 이동한 후 com.sun.management 노드와 HotSpotDiagnostic 노드를 차례로 연다. 그런 다음 Operations를 선택하고 오른쪽 분할창에 있는 "dumpHeap" 단추를 누른다. 첫 번째("String") 입력 상자에 덤프할 파일 이름을 입력하여 dumpHeap에 전달하면 전체 JVM 힙에 대한 스냅샷이 작성되어 해당 파일에 기록된다.
나중에 다양한 상용 프로파일러를 사용하여 파일을 분석하거나 VisualVM을 사용하여 스냅샷을 분석할 수 있다. (VisualVM은 Java 6에서 사용할 수 있으며 독립형 다운로드로도 사용할 수 있다.)
프로파일러 유틸리티로서 JConsole이 좋은 도구임에 틀림 없지만 그보다 더 좋은 도구도 있다. 분석 추가 기능이나 멋진 사용자 인터페이스를 갖춘 프로파일러도 있고 기본적으로 JConsole보다 더 많은 데이터를 추적하는 프로파일러도 있다.
JConsole의 진정한 매력은 전체 프로그램이 "평범한 구형 Java"로 작성되어 있다는 것이다. 이는 곧 Java 개발자라면 누구나 이와 같은 유틸리티를 작성할 수 있다는 것을 의미한다. 실제로 JDK에는 JConsole용 새 플러그인을 작성하여 JConsole을 사용자 정의하는 방법을 보여 주는 예제가 포함되어 있다(참고자료 참조). NetBeans를 기반으로 빌드된 VisualVM에서는 플러그인 개념을 훨씬 더 잘 활용한다.
JConsole(또는 VisualVM이나 기타 도구)이 원하는 기능을 제공하지 않거나, 추적하려는 항목을 추적하지 않거나, 원하는 방식으로 추적하지 않을 경우 사용자가 직접 코드를 작성할 수 있다. Java 코드가 너무 복잡해 보일지도 모르지만 언제라도 Groovy, JRuby 또는 기타 JVM 언어를 활용하여 코드를 빠르게 작성할 수 있다.
실제로 가장 필요한 것은 JMX를 통해 연결되는 사용하기 편리한 명령 도구이며, 원하는 데이터를 원하는 방식으로 정확히 추적할 수 있다.
Java 성능 모니터링은 JConsole이나 VisualVM에서 끝나지 않는다. JDK에는 대부분의 개발자가 모르고 있는 수많은 도구가 있다. 이 시리즈의 다음 기사에서는 필요한 성능 데이터를 더 자세히 살펴보는 데 도움이 되는 실험 수준의 몇 가지 명령 도구에 대해 살펴본다. 이러한 도구는 일반적으로 특정 데이터를 중점적으로 다루기 때문에 완전한 프로파일러에 비해 규모가 작은 경량 도구이다. 따라서 성능 오버헤드도 발생하지 않는다.
교육
- "모르고 있던 5가지 사항": Java 플랫폼에 대해 모르는 것이 많았다는 것을 일깨워 주는 이 시리즈에서는 사소하게 여겼던 Java 기술을 유용한 프로그래밍 팁으로 바꿔준다.
- "Monitoring and management using JMX"(Sun Microsystems): JMX와 JVM의 내장 인스트루멘테이션 도구를 사용하여 Java 애플리케이션 성능을 모니터링 및 관리하는 방법에 대해 알아보자.
- "Mustang JConsole"(Mandy Chung 저, Java.net, 2008년 5월): JConsole Plugin API를 사용하여 사용자 정의 플러그인을 빌드하는 방법에 대해 간략하게 소개한다.
- "Acquiring JVM Runtime Information"(Dustin Marx 저, Dustin's Software Development Cogitations and Speculations, 2009년 6월): JConsole과 VisualVM을 포함한 JDK의 내장 모니터링 및 관리 도구에 대한 데모를 볼 수 있다.
- "Build your own profiler"(Andrew Wilcox 저, developerWorks, 2006년 3월): Java 5 에이전트 인터페이스와 AOP를 사용하여 사용자 정의 프로파일러인 Java Interactive Profiler를 빌드하는 방법을 보여 준다.
- IBM Monitoring and Diagnostic Tools for Java: Health Center는 실행 중인 IBM Java Virtual Machine을 모니터링하는 기능을 제공하는 낮은 오버헤드의 진단 도구이다.
- developerWorks Java 기술 영역: Java 프로그래밍과 관련된 모든 주제를 다루는 여러 편의 기사를 찾아보자.
제품 및 기술 얻기
- VisualVM은 여러 명령행 JDK 도구와 경량 프로파일링 기능을 통합한 비주얼 도구이다.
토론
- My developerWorks 커뮤니티에 참여하자.
반응형
'Language > JAVA' 카테고리의 다른 글
| 처음 배우는 스프링 부트 2 (build.gradle) (2) | 2020.04.29 |
|---|---|
| 간단한 포트 확인용 에코 프로그램 (0) | 2013.01.29 |
| 개발자의 실수를 줄여주는 java.sql.Connection 만들기(퍼옴) (0) | 2012.04.20 |
| 엑셀 대용량 다운로드 가능하게 자바 만들기 (0) | 2012.04.05 |
| OOM(Out Of Memory) 없이 IBM Heapdump 파일 분석하기 (0) | 2012.02.15 |
개발자의 실수를 줄여주는 java.sql.Connection 만들기(퍼옴)
2012. 4. 20. 13:28
반응형
개발자의 실수를 줄여주는 java.sql.Connection 만들기
흔히 close()를 하지 않아서 발생하는 자원 누수 현상을 줄여주는 Connection 클래스를 만들어본다.
JDBC API 사용시 흔히 하는 개발자의 실수
JDBC API를 사용하여 데이터베이스 프로그래밍을 할 때 가장 많이 사용되는 코드는 아마도 다음과 같은 형태일 것이다.
그런데 위와 같은 프로그래밍을 할 때 흔히 하는 실수가 close()를 제대로 해 주지 않는 것이다. 특히, 하나의 메소드에서 5-10개의 (PreparedStatement를 포함한)Statement와 ResultSet을 사용하는 경우에는 개발자의 실수로 같은 Statement를 두번 close() 하고 한두개의 Statement나 ResultSet은 닫지 않는 실수를 하곤 한다. 이처럼 close() 메소드를 알맞게 호출해주지 않을 경우에는 다음과 같은 문제가 발생한다.
Statement를 자동으로 닫아주는 MVConnection 클래스 구현
실제로 필자도 앞에서 언근했던 문제들 때문에 고생하는 사람들을 종종 봐 왔었으며, 그때마다 그 버그를 고치기 위해서 소스 코드를 일일이 찾아보는 노가다를 하는 개발자들을 보기도 했다. 그래서 만든 클래스가 있는데, 그 클래스의 이름을 MVConnection이라고 붙였다. 이름이야 여러분의 입맛에 맛게 수정하면 되는 것이므로, 여기서는 원리만 간단하게 설명하도록 하겠다.
먼저, MVConnection을 구현하기 전에 우리가 알고 있어야 하는 기본 사항이 있다. JDBC API를 유심히 읽어본 사람이라면 다음과 같은 내용을 본 적이 있을 것이다.
다음은 MVConnection 클래스의 핵심 코드이다.
위 코드를 보면 Statement를 저장하기 위한 List와 그 List에 저장된 Statement 객체를 모두 닫아주는 closeAll() 이라는 메소드가 정의되어 있다. 바로 이 List와 closeAll() 메소드가 이 MVConnection 클래스의 핵심이다. Statement를 생성해주는 메소드(createStatement, prepareCall, prepareStatement)를 보면 생성된 Statement를 statemetList에 추가해주는 것을 알 수 있다. 이렇게 저장된 Statement는 실제로 Connection을 닫을 때, 즉 Connection의 close() 메소드를 호출할 때 닫힌다. (코드를 보면 close() 메소드에서 closeAll() 메소드를 먼저 호출하고 있다.) 따라서, close() 메소드만 호출하면 그와 관련된 모든 Statement와 ResultSet은 자동으로 닫히게 된다.
위 코드에서 다른 메소드들은 모두 다음과 같이 간단하게 구현된다.
MVConnection은 java.sql.Connection을 implements 하기 때문에, 그 자체가 Connection으로 사용될 수 있다. 따라서 MVConnection을 사용한다고 해서 특별히 코드가 많이 변경되지는 않으며 다음과 같이 전체적으로 코드가 단순하게 바뀐다.
때에 따라서는 Connection을 close() 하지 않고 커넥션 풀에 되돌려 놔야 할 때가 있다. 그런 경우에는 다음과 같은 형태의 코드를 사용하면 된다.
즉, Connection을 닫지 않는 경우에는 위와 같이 커넥션 풀에 반환하기 전에 closeAll() 메소드 하나만을 호출해주면 된다. 그러면 Connection과 관련된 모든 Statement, ResultSet 등이 닫히게 된다.
결론
필자의 경우는 이 글에서 작성한 MVConnection을 실제 프로젝트에 응용하여 코드 작성의 편리함 뿐만 아니라 실수로 인해서 발생하는 시스템의 버그 문제를 어느 정도 해결할 수 있었다. 특히, Statement를 생성하거나 ResultSet을 생성할 때 발생하는 커서부족 문제를 획기적으로 줄일 수 있었다. 여러분도 이 클래스를 응용하여 보다 나은 방법으로 코딩의 실수 및 자원의 낭비를 줄일 수 있는 클래스를 작성해보기 바란다.
JDBC API 사용시 흔히 하는 개발자의 실수
JDBC API를 사용하여 데이터베이스 프로그래밍을 할 때 가장 많이 사용되는 코드는 아마도 다음과 같은 형태일 것이다.
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
try {
conn = DBPool.getConnection(); //
stmt = conn.createStatement();
rs = stmt.executeQuery(..);
...
} catch(SQLException ex) {
// 예외 처리
} finally {
if (rs != null) try { rs.close(); } catch(SQLException ex) {}
if (stmt != null) try { stmt.close(); } catch(SQLException ex) {}
if (conn != null) try { conn.close(); } catch(SQLException ex) {}
}
Statement stmt = null;
ResultSet rs = null;
try {
conn = DBPool.getConnection(); //
stmt = conn.createStatement();
rs = stmt.executeQuery(..);
...
} catch(SQLException ex) {
// 예외 처리
} finally {
if (rs != null) try { rs.close(); } catch(SQLException ex) {}
if (stmt != null) try { stmt.close(); } catch(SQLException ex) {}
if (conn != null) try { conn.close(); } catch(SQLException ex) {}
}
그런데 위와 같은 프로그래밍을 할 때 흔히 하는 실수가 close()를 제대로 해 주지 않는 것이다. 특히, 하나의 메소드에서 5-10개의 (PreparedStatement를 포함한)Statement와 ResultSet을 사용하는 경우에는 개발자의 실수로 같은 Statement를 두번 close() 하고 한두개의 Statement나 ResultSet은 닫지 않는 실수를 하곤 한다. 이처럼 close() 메소드를 알맞게 호출해주지 않을 경우에는 다음과 같은 문제가 발생한다.
- Statement를 닫지 않을 경우, 생성된 Statement의 개수가 증가하여 더 이상 Statement를 생성할 수 없게 된다.
- close() 하지 않으므로 불필요한 자원(네트워크 및 메모리)을 낭비하게 된다.
- 커넥션 풀을 사용하지 않는 상황에서 Connection을 닫지 않으면 결국엔 DBMS에 연결된 새로운 Connection을 생성할 수 없게 된다.
Statement를 자동으로 닫아주는 MVConnection 클래스 구현
실제로 필자도 앞에서 언근했던 문제들 때문에 고생하는 사람들을 종종 봐 왔었으며, 그때마다 그 버그를 고치기 위해서 소스 코드를 일일이 찾아보는 노가다를 하는 개발자들을 보기도 했다. 그래서 만든 클래스가 있는데, 그 클래스의 이름을 MVConnection이라고 붙였다. 이름이야 여러분의 입맛에 맛게 수정하면 되는 것이므로, 여기서는 원리만 간단하게 설명하도록 하겠다.
먼저, MVConnection을 구현하기 전에 우리가 알고 있어야 하는 기본 사항이 있다. JDBC API를 유심히 읽어본 사람이라면 다음과 같은 내용을 본 적이 있을 것이다.
- Statement를 close() 하면 Statement의 현재(즉, 가장 최근에 생성한) ResultSet도 close() 된다.
- ResultSet은 그 ResultSet을 생성한 Statement가 닫히거나, 또는 executeQuery 메소드를 실행하는 경우 close() 된다.
다음은 MVConnection 클래스의 핵심 코드이다.
public class MVConnection implements Connection {
private Connection conn; // 실제 커넥션
private java.util.List statementList; // statement를 저장
public MVConnection(Connection conn) {
this.conn = conn;
statementList = new java.util.ArrayList();
}
public void closeAll() {
for (int i = 0 ; i < statementList.size() ; i++) {
Statement stmt = (Statement)statementList.get(i);
try {
stmt.close();
} catch(SQLException ex) {}
}
}
public void close() throws SQLException {
this.closeAll(); conn.close();
}
public Statement createStatement() throws SQLException {
Statement stmt = conn.createStatement();
statementList.add(stmt);
return stmt;
}
public CallableStatement prepareCall(String sql) throws SQLException {
CallableStatement cstmt = conn.prepareCall(sql);
statementList.add(cstmt);
return cstmt;
}
public PreparedStatement prepareStatement(String sql) throws SQLException {
PreparedStatement pstmt = conn.prepareStatement(sql);
statementList.add(pstmt);
return pstmt;
}
...
}
private Connection conn; // 실제 커넥션
private java.util.List statementList; // statement를 저장
public MVConnection(Connection conn) {
this.conn = conn;
statementList = new java.util.ArrayList();
}
public void closeAll() {
for (int i = 0 ; i < statementList.size() ; i++) {
Statement stmt = (Statement)statementList.get(i);
try {
stmt.close();
} catch(SQLException ex) {}
}
}
public void close() throws SQLException {
this.closeAll(); conn.close();
}
public Statement createStatement() throws SQLException {
Statement stmt = conn.createStatement();
statementList.add(stmt);
return stmt;
}
public CallableStatement prepareCall(String sql) throws SQLException {
CallableStatement cstmt = conn.prepareCall(sql);
statementList.add(cstmt);
return cstmt;
}
public PreparedStatement prepareStatement(String sql) throws SQLException {
PreparedStatement pstmt = conn.prepareStatement(sql);
statementList.add(pstmt);
return pstmt;
}
...
}
위 코드를 보면 Statement를 저장하기 위한 List와 그 List에 저장된 Statement 객체를 모두 닫아주는 closeAll() 이라는 메소드가 정의되어 있다. 바로 이 List와 closeAll() 메소드가 이 MVConnection 클래스의 핵심이다. Statement를 생성해주는 메소드(createStatement, prepareCall, prepareStatement)를 보면 생성된 Statement를 statemetList에 추가해주는 것을 알 수 있다. 이렇게 저장된 Statement는 실제로 Connection을 닫을 때, 즉 Connection의 close() 메소드를 호출할 때 닫힌다. (코드를 보면 close() 메소드에서 closeAll() 메소드를 먼저 호출하고 있다.) 따라서, close() 메소드만 호출하면 그와 관련된 모든 Statement와 ResultSet은 자동으로 닫히게 된다.
위 코드에서 다른 메소드들은 모두 다음과 같이 간단하게 구현된다.
public boolean getAutoCommit() throws SQLException {
return conn.getAutoCommit();
}
return conn.getAutoCommit();
}
MVConnection은 java.sql.Connection을 implements 하기 때문에, 그 자체가 Connection으로 사용될 수 있다. 따라서 MVConnection을 사용한다고 해서 특별히 코드가 많이 변경되지는 않으며 다음과 같이 전체적으로 코드가 단순하게 바뀐다.
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
try {
// MV Connection 생성
conn = new MVConnection(DBPool.getConnection());
stmt = conn.createStatement();
rs = stmt.executeQuery(..);
...
} catch(SQLException ex) {
// 예외 처리
} finally {
// conn 만 close() 해준다.
if (conn != null) try { conn.close(); } catch(SQLException ex) {}
}
Statement stmt = null;
ResultSet rs = null;
try {
// MV Connection 생성
conn = new MVConnection(DBPool.getConnection());
stmt = conn.createStatement();
rs = stmt.executeQuery(..);
...
} catch(SQLException ex) {
// 예외 처리
} finally {
// conn 만 close() 해준다.
if (conn != null) try { conn.close(); } catch(SQLException ex) {}
}
때에 따라서는 Connection을 close() 하지 않고 커넥션 풀에 되돌려 놔야 할 때가 있다. 그런 경우에는 다음과 같은 형태의 코드를 사용하면 된다.
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
try {
// MV Connection 생성
conn = new MVConnection(DBPool.getConnection());
stmt = conn.createStatement();
rs = stmt.executeQuery(..);
...
} catch(SQLException ex) {
// 예외 처리
} finally {
if (conn != null) try {
((MVConnection)conn).closeAll();
DBPool.returnConnection(conn);
} catch(SQLException ex) {}
}
Statement stmt = null;
ResultSet rs = null;
try {
// MV Connection 생성
conn = new MVConnection(DBPool.getConnection());
stmt = conn.createStatement();
rs = stmt.executeQuery(..);
...
} catch(SQLException ex) {
// 예외 처리
} finally {
if (conn != null) try {
((MVConnection)conn).closeAll();
DBPool.returnConnection(conn);
} catch(SQLException ex) {}
}
즉, Connection을 닫지 않는 경우에는 위와 같이 커넥션 풀에 반환하기 전에 closeAll() 메소드 하나만을 호출해주면 된다. 그러면 Connection과 관련된 모든 Statement, ResultSet 등이 닫히게 된다.
결론
필자의 경우는 이 글에서 작성한 MVConnection을 실제 프로젝트에 응용하여 코드 작성의 편리함 뿐만 아니라 실수로 인해서 발생하는 시스템의 버그 문제를 어느 정도 해결할 수 있었다. 특히, Statement를 생성하거나 ResultSet을 생성할 때 발생하는 커서부족 문제를 획기적으로 줄일 수 있었다. 여러분도 이 클래스를 응용하여 보다 나은 방법으로 코딩의 실수 및 자원의 낭비를 줄일 수 있는 클래스를 작성해보기 바란다.
반응형
'Language > JAVA' 카테고리의 다른 글
| 간단한 포트 확인용 에코 프로그램 (0) | 2013.01.29 |
|---|---|
| Java 성능 모니터링에 대해 모르고 있던 5가지 사항, Part 1 (0) | 2012.05.02 |
| 엑셀 대용량 다운로드 가능하게 자바 만들기 (0) | 2012.04.05 |
| OOM(Out Of Memory) 없이 IBM Heapdump 파일 분석하기 (0) | 2012.02.15 |
| System.out.println()은 잊어라 log4sql이 온다. (0) | 2011.03.15 |
윈도우 hosts 파일 오류시 조치 방법
2012. 4. 12. 20:54
반응형
Ping request could not find host xxxx Please check the name and try again
http://support.microsoft.com/kb/972034
MicrosoftFixit50267.msi반응형
'Windows' 카테고리의 다른 글
| 윈도우 98 고스트 생성을 위한 이미지 파일 (0) | 2012.12.30 |
|---|---|
| 윈도우 7 업그레이드 관리자 (0) | 2012.11.02 |
| windows XP USB 설치본 만들기 (0) | 2012.03.08 |
| Windows 7 Usb 설치 본 만들기... (0) | 2012.03.08 |
| Windows XP sp3 서비스팩 3 IE8 설치 오류 (1) | 2012.02.15 |
엑셀 대용량 다운로드 가능하게 자바 만들기
2012. 4. 5. 16:23
반응형
엑셀을 처리하는 방법
1. 일반적인 방법
- DB <---> WAS (JAVA) 파일 생성 <---> JSP 다운로드
- 문제점 : WAS에 메모리에서 엑셀 파일을 만들기 때문에 메모리 할당 공간이 부족할 때는 OOM(Out Of Memory)으로
힙 덤프를 사정없이 발사 !
2. 대용량 엑셀 처리 방법
- 엑셀을 생성할 때 XML 방식으로 생성함
http://en.wikipedia.org/wiki/Microsoft_Office_XML_formats#Excel_XML_Spreadsheet_example
- outputStream으로 행별로 Text를 써야 메모리에 한꺼번에 올리지 않아 WAS가 OOM를 뿜으면서 죽지 않음.
※ 첨부된 자바파일을 참고함
- 대용량이므로 속도에 신경 쓰지 않을 수 없다 !!!
그러므로 Fetch Size(JAVA에서 Oracle를 사용할 때 가지고오는 row의 양...)을 조절하여 성능향샹의 효과 까지 볼수 있다.
후후... 재미있는건... 난 자바를 잘 모른다...
개발자들도 원인을 잘 찾지 않는다...
귀찮은 걸까... 해결하고 싶지 않을껄까...
난 인프라 담당인데 하하하 -_-
반응형
'Language > JAVA' 카테고리의 다른 글
| Java 성능 모니터링에 대해 모르고 있던 5가지 사항, Part 1 (0) | 2012.05.02 |
|---|---|
| 개발자의 실수를 줄여주는 java.sql.Connection 만들기(퍼옴) (0) | 2012.04.20 |
| OOM(Out Of Memory) 없이 IBM Heapdump 파일 분석하기 (0) | 2012.02.15 |
| System.out.println()은 잊어라 log4sql이 온다. (0) | 2011.03.15 |
| Log for SQL (PL/SQL 개발환경에서 로그 정보 확인하기) (0) | 2011.03.15 |
해커그룹 어노니머스, 해킹 전용 OS 공개
2012. 3. 16. 12:52
반응형
해커그룹 어노니머스, 해킹 전용 OS 공개
뭐... 나중에 연구해봐야지.. 하하하
관련기사 : http://www.bloter.net/archives/101051
다운로드 주소 :
http://anonymous-os.tumblr.com/download
반응형
'보안' 카테고리의 다른 글
| 보안 교육 3일 교육 내용 (0) | 2014.05.23 |
|---|---|
| 시큐어 코딩 점검 툴 (0) | 2013.05.10 |
| 웹 어플리케이션 보안 가이드 2010 (0) | 2012.01.11 |
| [G-PIN] 공공아이핀 설치하기 (0) | 2011.08.09 |
| 보안 관련 사이트 (0) | 2010.11.05 |
windows XP USB 설치본 만들기
2012. 3. 8. 17:57
반응형
반응형
'Windows' 카테고리의 다른 글
| 윈도우 7 업그레이드 관리자 (0) | 2012.11.02 |
|---|---|
| 윈도우 hosts 파일 오류시 조치 방법 (0) | 2012.04.12 |
| Windows 7 Usb 설치 본 만들기... (0) | 2012.03.08 |
| Windows XP sp3 서비스팩 3 IE8 설치 오류 (1) | 2012.02.15 |
| 윈도우즈 업데이트 오류 (0) | 2012.02.15 |
Windows 7 Usb 설치 본 만들기...
2012. 3. 8. 17:42
반응형
반응형
'Windows' 카테고리의 다른 글
| 윈도우 hosts 파일 오류시 조치 방법 (0) | 2012.04.12 |
|---|---|
| windows XP USB 설치본 만들기 (0) | 2012.03.08 |
| Windows XP sp3 서비스팩 3 IE8 설치 오류 (1) | 2012.02.15 |
| 윈도우즈 업데이트 오류 (0) | 2012.02.15 |
| Windows Dump 분석하기 (0) | 2012.01.20 |