그루비 groovy - 제이공작소

http://www.quora.com/Why-does-Quora-use-MySQL-as-the-data-store-rather-than-NoSQLs-such-as-Cassandra-MongoDB-CouchDB-etc

왜, Quora는 몽고디비같은거를 안쓰고 MysQL을 쓰나요? 에 대한 대답.
약간 요약 번역

1. 애플리케이션쪽에서 파티션을 담당한다면, MySQL의 확장성은 문제가 되지 않는다. Facebook에서는 1800대의 MySQL 서버를 DBA두명이 관리했다(2008년에). 파티션으로 나누면 JOIN기능을 사용할 수 없지만 NoSQL들도 마찬가지다

2. 카산드라(Cassandra), 몽고디비(MongoDB), 카우치디비(CouchDB)는 생각만큼 안정적이거나 확장성있는게 아니다.

3. 정보 저장소는 중요한 부분이다. 안정성이 확보되지 않은 신규 기술을 적용하기에 적당한 부분이 아니다.

4. MySQL 서버만가지고도 충분히 확장할 수 있다. CPU를 더 꽂고 RAM을 더 설치하고 replca를 이용하면 된다. 데이터베이스앞에 memcached를 둔다면 데이터베이스는 write만 담당하면 된다.

5. MySQL을 애플리케이션 측에서 파티셔닝할때는 여러가지 문제가 생긴다. 이문제들은 애플리케이션과 MySQL 사이에 분산자동화를 위한 레이어를 하나두면 된다. FriendFeed에서 좋은 예제를 만들어뒀다. ( http://bret.appspot.com/entry/how-friendfeed-uses-mysql )

6. 개인적으로 스키마가 있는 데이터베이스가 '올바른' 데이터베이스 모델이라고 생각한다. 지금의 NoSQL 붐은 누군가 약간 느슨한 문법을 지원하는 분산형 SQL서버를 구현하면 사그러들꺼라고 생각한다.



나도 운영중인 서버에는 NoSQL적용 못하고 있지만, 신규서비스를 만들때는 이렇게까지 보수적으로 가지는 않을 것 같다. 재미가없잖아!

어쨌든 저 프렌드피드 링크(http://bret.appspot.com/entry/how-friendfeed-uses-mysql)는 오래된 거지만 아직도 읽어볼만한 것 같다.

아무리 뒤져도 없길래 이런 방법도 있다고.. 올립니다.

---

스마트에디터 http://dev.naver.com/projects/smarteditor/ 를 사용하고 있는데, 초기에 주어진 높이와 너비대로 에디터를 생성하는 것은 문제가 없지만, 사용자가 원할때 높이나 너비를 조정해야 할일이 있었다.

에디터의 높이를 조절하는 코드는 잘 동작하는데, 너비는 제어가 되질 않았다. 높이 제어는 이 코드로 잘 동작했다.

저 newheight 부분에 값을 적어주면 끝, 하지만, newwidth 에 값을 적어주어도, 너비는 그대로였다.

소스를 뒤져서 동작하게했다. 이렇게 하는게 맞는지 어쩐지 잘 모르겠다. 어쨌든 두줄만 고쳤고, 동작한다.

먼저, HuskyEZCreator.js 에서

var elIFrame;

try{
     elIFrame = document.createElement("<IFRAME frameborder=0 scrolling=no>");
}catch(e){
     elIFrame = document.createElement("IFRAME");
     elIFrame.setAttribute("frameborder", "0");
     elIFrame.setAttribute("scrolling", "no");
}

을 찾아서 아래처럼 고칩니다.

var elIFrame;
try{
    elIFrame = document.createElement("<IFRAME id='huskey_editor_jinto_set_id' frameborder=0 scrolling=no>");
}catch(e){
    elIFrame = document.createElement("IFRAME");
    elIFrame.setAttribute("frameborder", "0");
    elIFrame.setAttribute("id", "huskey_editor_jinto_set_id");
    elIFrame.setAttribute("scrolling", "no");
}

(물론 huskey_editor_jinto_set_id 는 원하시는 문자열로.. 바꾸셔도 됩니다요.. ^^)


에디터의 너비를 제어하는 코드 (textarea의  id 가 "textarea_id"라고 가정하고, 에디터생성할때 아이디는 my_content라고 주었다고 가정. 그리고, jquery를 사용)를 이렇게 만들어주시면 됩니다.

ㅌvar width=670; // 원하는 너비
$("#textarea_id").css('width',width);
$("#textarea_id").outerWidth(width+20); // 이건 없어도 상관없슴. 테두리따위때문에 필요한 분이 있을 수도.
$("#huskey_editor_jinto_set_id").css('width',width);
$("#huskey_editor_jinto_set_id").outerWidth(width+20);   // 이건 없어도 상관없슴.
oEditors.getById["my_content"].exec("MSG_EDITING_AREA_RESIZE_STARTED", []); // 이 코드는 없어도 될지도.
oEditors.getById["my_content"].exec("RESIZE_EDITING_AREA_BY", [0, 0]); // 이 코드는 없어도 될지도.
oEditors.getById["my_content"].exec("MSG_EDITING_AREA_RESIZE_ENDED", []); // 이 코드는 없어도 될지도.

이상입니다~.

검색하는 분들을 위해 - 스마트에디터,넓이,너비,폭,width,제어,조작,동적

웹서버에서 이미지 파일 다운로드 받기

new File("downloadedimg.jpg").withOutputStream { os -> new URL("http://server/img_uri.jpg").withInputStream { is -> os << is } } 

몽고디비는 계속 크래시 리포트가 올라온다.  그래도 개발팀의 대응을 보면 살아움직이는 프로젝트라는 느낌이 든다. 최근에는 포스퀘어랑 몽고디비가 자신들이 겪은 일을 그대로 외부에 공개해줬는데, 그런 분위기도 상당히 부럽고 내용에도 참고할만한 점이 있다.


사건의 개요는 이렇다.

1. 포스퀘어는 사용자정보를 몽고디비에 저장한다.
2. 몽고디비는 두대의 아마존 EC2(RAM 66G)에서 서비스한다.
3. 샤딩(shard)을 했지만, 균등하게 분산되지 않았다.
4. 어느 순간 한서버에는 67G, 다른 서버에는 50G의 데이터가 저장되었다.
5. 메모리가 넘치면서 디스크로 페이징이 되기 시작했다.
6. 응답속도가 느려지면서 쿼리 요청이 쌓이고, 페이징은 가속되었다.
7. 세번째 샤드를 추가했다.
   (몽고디비 최근 버전에 auto-shard가 추가되었습니다.)
8. 몽고디비는 4K단위로 움직이는데, 포스퀘어의 체크인 데이터는 300 byte밖에 안된다.
9. 하나의 체크인데이터를 새 샤드에 생생해봤자, 기존서버의 4K 는 그대로 있다.
10. 몽고디비의 compaction 기능을 사용해보았다.
11. 아마존의 디스크는 네트웍스토리지다. 느리다. 컴팩션도 너무 느렸다.
    (몽고디비의 컴팩션은 디스크에서 동작. EBS는 네트웍 스토리지)
12. 그래서, 어쩔수없이... 사용자정보 전체를 백업으로부터 새로 읽어들였다.
13. 이제 세개의 샤드에 고르게 분산 저장되었다.


원본 :  http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-from-the-foursquare.html (원문에는 위의 개요말고도 볼만한 내용이 더 있음)

카우치디비(couchdb) 1.0 이 나왔다는 소식을 전했더랬습니다. 거기서 300배가 빨라졌다고 주장하네,라고 썼는데, 얼마나 빨라졌는지 궁금해서 테스트를 돌려봤슴다. 이번에도 지난번처럼 몽고디비(mongodb)와 비교했습니다.


테스트 환경 / 설치
-------------------
하드웨어는 메모리 4G, CPU는 2GHz Xeon (2core) 이었구요. (네, 이제 퇴역할 때가 다가오고 있는 기곕니다..)

데비안에서 테스트를 해보고 싶어서 고생좀했습니다. apt-pin 으로 testing, unstable을 열어주는 수밖에는 없는것 같습니다. 다른 시도들은 모두 실패했는데, apt-pin 을 한 후에

[code shell]sudo apt-get install build-essential libmozjs-dev
sudo apt-get install libicu-dev libcurl4-openssl-dev erlang
tar -zxvf apache-couchdb-1.0.1.tar.gz
cd apache-couchdb-1.0.1
./configure --prefix=/opt/couchdb
make
sudo /opt/couchdb/bin/couchdb [/code]

로 성공했습니다. 다른 방식들은 자바스크립트 관련한 오묘한 오류가 발생하네요.

mongodb는 apt-pin 설정만 해주면 최신버전인 1.6.1이 잘 설치됩니다. unstable이지만 패키지에는 들어가있습니다.




테스트 데이터
--------------
얼마나 속도가 향상되었는지만 궁금했기 때문에, 어떤 게시판의 게시물 251723개를 디비에 넣어보는 테스트만 해보았습니다. 지난번에는 이 테스트에 8시간정도가 걸렸었었습니다. 당시에 벌크 인서트를 사용하면 30분정도 였고, 동일한 테스트를 mongodb에서 수행하면 13분이었슴다.

결과부터 살짝 공개하면, 8시간 걸리던 테스트가 이번에는 49분이네요!  (300배는 아니지만, 환경이 바뀌었기 때문일 수도 있으니까, 카우치팀이 꽤 열심히 일한것 같습니다.)


뷰 엔진
-------
인서트도 빨라졌지만, 더 감동적인 것은 map/reduce 함수입니다.

[code javascript]function(doc) {
 emit(doc.doc_type, 1);
}

function(key, values) {
 return sum(values);
}[/code]

전에는 데이터를 수정하고 뷰를 갱신하면, 기다리는 시간이 너무 길어서, 테스트던 뭐던 도저히 실무에는 적용하기 힘들겠다는 정도였습니다.

다행히 1.0.1 버전은 그렇지는 않습니다. 데이터 변형이나 추가가 엄청나게 많은 경우에는 어떨지 모르겠지만. 만개 정도의 데이터를 추가한 다음, 뷰를 갱신해보니 1초이내에 응답을 만들어냅니다. 천개정도 추가에 4초까지 걸렸던 지난 버전보다는 좋아졌습니다. (뷰화면을 갱신해도 인서트 작업이 느려지는 등의 부작용도 보이지 않았구요.)

데이터 갱신할 때 인덱스를 건드려주는 타입보다는 느릴 수밖에 없겠지만, 체감속도는 견딜만 한 정도네요.




속도비교
--------
데이터 삽입 속도
CouchDB : 49분
CouchDB bulk : 16분
MongoDB : 3 분

MongoDB가 CouchDB보다 16배 빠릅니다.
지난번 비교에서는 (mongodb : 14 분, couchdb: 8시간) 몽고디비가 34배 빨랐었다.
삽입속도와 더불어 뷰엔진에서 인덱스처리도 훨씬 견딜만해졌다는 점도 기억해줘야겠습니다.


데이터 파일크기
CouchDB : 2.5G
MongoDB : 4.2G

몽고디비쪽에 파일 크기와 관련해서 무언가가 달라진 것 같습니다. 꽤 커졌고, 파일 크기에 대해 컴플레인하는 글도 보입니다. 뭐, 부담스러울 정도는 아닙니다만.



결론
----
전에는.... 카우치디비에서 자바스크립트로 Map/Reduce 라는 것을 공부해보고 싶었지만, 조금만 데이터가 많아도 속도가 느려서 공부할 맛이 안났었습니다.

이제 1.0.1 을 설치해보시면 그런대로 테스트/실무에서 사용해볼만한 속도를 내줍니다. 다행입니다.

시작부터 여러가지로 차이가 나는 시스템들이기 때문에 어느 것을 선택할지 계속 망설이는 중이기는 하지만, 현재로써는 둘다 실무의 한부분 (문제가 생기면 서비스에서 빠져도 되는 부분에만..) 에 적용해보기로 했습니다.

실무에서 어떤 문제/성과가 있는지는 다음번에 올리겠습니다. (테스트할 사이트는 3만/1일 PV 라서 헤비한 사이트에서도 견디는가 따위보다는 써보니까 어느쪽이 더 편하더라, 정도가 될것 같습니다. 누군가도 분명히 테스트해봤을 것 같은데... 한글 자료는 별로 없네요.)


----
P.S. 카우치/몽고 모두 우분투용으로는 최신버전이 있지만, 데비안에서는 조금 헤매야 합니다. 게다가 apt-pin은 별로 내키지 않구요. 그래서. 서버 OS를 바꿔볼까.. 또 망설이다가, http://qa.debian.org/developer.php?login=nslater%40tumbolia.org 를 발견했다. 아래쪽에 현재까지 알려진 (아직 수정되지않은) couchdb의 버그갯수가 나와있습니다. 그렇습니다. 데비안이 더 보수적입니다. 다시한번 데비안으로 주저앉기로 했습니다. 조금만 기다리면 1.1 쯤부터는 프로덕션 서버에도 설치할 수 있을지도...

P.P.S  테스트는 굳이 그루비로 진행했습니다. 몽고디비쪽의 드라이버가 그루비 1.7.1 에서만 제대로 동작한다는 점만 빼면 여전히 쓰기 편하더군요.

넷빈즈에서 톰캣에 곧바로 디플로이 할 수 있는 방법은 요기에 : http://groovy.pe.kr/51
이제 넷빈즈에서 그루비, 스칼라로 JDBC에 접근하는 법을 보자.

먼저, 서버와 로컬에 scala 설치 (현재 버전은 2.7.7), groovy 설치 (2.7.0)
서버쪽에서는 /usr/share/tomcat6/lib 에서
[code]
ln -s /usr/share/groovy/lib/groovy-all-1.7.0.jar
ln -s /usr/share/java/scala-library.jar
ln -s /usr/share/java/scala-dbc.jar
ln -s /usr/share/java/mysql.jar
[/code]
따위를 해둔다.


그리고 넷빈즈의, library에서 Add Jar를 해서 scala-library.jar와 scala-compiler.jar, groovy-all-1.7.0 를 추가해준다.

그리고, 문제의 build.xml 은 아래쪽에 실었다. 시행착오 끝에 만들긴 했는데, 나중에 정식 지원되면 허무할듯.

이제는 src/java 자리에 xx.java, xx.scala, xx.groovy 로 서블릿 만들면 모두 잘 컴파일되고, war 만들어지고, 디플로이하면 서버에 올라간다. ^^


그리고, 여전히 속도테스트를 해봤는데, 테스트는 데이터베이스 서버에 접속해서 데이터 긁어오고, 브라우저로 쏴주는 단순한 것. (레코드 50만개중에서 200개를 가져오게 했다)

자바로 만든 서블릿은
Time per request:       1.273 [ms] (mean)
Time per request:       0.318 [ms] (mean, across all concurrent requests)

스칼라로 만든 서블릿은
Time per request:       1.261 [ms] (mean)
Time per request:       0.315 [ms] (mean, across all concurrent requests)

그루비로 만든 서블릿은
Time per request:       1.836 [ms] (mean)
Time per request:       0.459 [ms] (mean, across all concurrent requests)

그루비가 느렸다. 저게 문제가 될정도는 아닌 것같다. 게다가 Groovy++도 나오면.. ㅎㅎ (스칼라는... 자바버전보다 빠르게 나왔는데, 단순 스트레스 테스트였기 때문인.. 아닌지 모르겠다.)
하지만, 아직 나에겐 스칼라 문법은 어색 어색. 그루비가 코딩하기 편했다.

자. 문제의 build.xml

[code]
<target name="taskdef-scala">
    <taskdef resource="scala/tools/ant/antlib.xml"  >
        <classpath>
            <pathelement location="${file.reference.scala-compiler.jar}" />
            <pathelement location="${file.reference.scala-library.jar}" />
        </classpath>
    </taskdef>
</target>


<taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc"
         classpath="c:/Tools/groovy/embeddable/groovy-all-1.7.0.jar"/>


<target name="-init-macrodef-javac" depends="taskdef-scala">
    <macrodef name="javac" uri="http://www.netbeans.org/ns/web-project/2">
        <attribute default="${src.dir}" name="srcdir"/>
        <attribute default="${build.classes.dir}" name="destdir"/>
        <attribute default="${javac.classpath}:${j2ee.platform.classpath}" name="classpath"/>
        <attribute default="${includes}" name="includes"/>
        <attribute default="${excludes}" name="excludes"/>
        <attribute default="${javac.debug}" name="debug"/>
        <attribute default="${empty.dir}" name="gensrcdir"/>
        <element name="customize" optional="true"/>
        <sequential>
            <property location="${build.dir}/empty" name="empty.dir"/>
            <mkdir dir="${empty.dir}"/>

            <groovyc  destdir="@{destdir}" srcdir="@{srcdir}"
                      encoding="utf-8"
                      excludes="@{excludes}"
                      includeantruntime="false"
                      includes="@{includes}"
                      >
                <src>
                    <dirset dir="@{gensrcdir}" erroronmissingdir="false">
                        <include name="*.groovy"/>
                    </dirset>
                </src>
                <classpath>
                    <path path="@{classpath}"/>
                </classpath>
            </groovyc>

            <javac debug="@{debug}" source="${javac.source}" target="${javac.target}"
                   srcdir="@{srcdir}" destdir="@{destdir}"
                   deprecation="${javac.deprecation}"
                   encoding="${source.encoding}" excludes="@{excludes}"
                   includeantruntime="false" includes="@{includes}">
                <src>
                    <dirset dir="@{gensrcdir}" erroronmissingdir="false">
                        <include name="*.java"/>
                    </dirset>
                </src>
                <classpath>
                    <path path="@{classpath}"/>
                </classpath>
                <compilerarg line="${endorsed.classpath.cmd.line.arg}"/>
                <compilerarg line="${javac.compilerargs}"/>
                <customize/>
            </javac>

            <scalac srcdir="@{srcdir}"
                    destdir="@{destdir}">
                <include name="**/*.scala"/>
                <classpath>
                    <pathelement location="${file.reference.scala-compiler.jar}" />
                    <pathelement location="${file.reference.scala-library.jar}" />
                    <path path="@{classpath}"/>
                </classpath>
            </scalac>
        </sequential>
    </macrodef>
</target>
[/code]
* 그루비 참고 : http://www.ighani.info/?p=32

로컬에 넷빈즈와 톰캣을 설치하면, 연동하는데 아무 문제가 없다. 하지만 톰캣이 외부에 있다면? 구글로 remote tomcat server deploy netbeans 를 종일 검색했다. 끙끙거리고 실패했던 시간들에 비하면 허무할 만큼 간단한 해법을 찾았다.

프로젝트에 build.xml에 다음 내용 추가
[code xml]
  <target name="tomcat-deploy-war" description="Deploy the App to Tomcat">
    <taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"
                 classpath="c:/TOMCAT_DIR/lib/catalina-ant.jar"/>
                 <dirname file="${dist.war}" property="dist.jar.dir"/>
                 <mkdir dir="${dist.jar.dir}"/>
    <deploy update="true"
            url="http://server_url:serverport/manager"
            username="admin"
            password="YOUR PASSWORD"
            path="/"
            war="file:d:/PROJECT_DIR/${dist.war}/"/>
  </target>

  <target depends="init,compile,compile-jsps,-pre-dist,-do-dist-with-manifest,-do-dist-without-manifest,tomcat-deploy-war" name="do-dist">
  </target>
[/code]
(조기에서.. TOMCAT_DIR 과 PROJECT_DIR 을 넷빈즈 내부 변수로 바꾸는 것은 어찌하는 것인지 못찾음. 아는 분은 조언바랍니다.)

서버의 /etc/tomcat6/tomcat-users.xml
[code]<user username="admin" password="YOUR PASSWORD" roles="standard,admin,manager"/>[/code]


환경 : 넷빈즈 6.8, 톰캣 6, 데비안 5

무식한 스트레스 테스트를 해보았다.

[code]ab -kc5 -t10 http://test_server_ip/test_db_connect.jsp[/code]

에서 동시접속과 시간을 조금씩 늘려가면서.. 테스트해보는 것.
테스트 페이지의 내용은 데이터베이스에서 몇개의 레코드를 보여주는 정도.


아주 단순한 응급 처치

/etc/init.d/tomcat6에 메모리를 512메가까지 쓰도록 설정해줬다.
[code]JAVA_OPTS="-Djava.awt.headless=true -Xms512M -Xmx512M"[/code]

데비안에서 톰캣6의 기본 메모리는 최대 128까지 쓸수있도록 설정되어있다. 저게 전부는 아닐꺼고, 실전에서는 더 세련된 방법이 있을 것도 같지만..


관련 오류 : java.lang.OutOfMemoryError: Java heap space
참고: http://heedy.pe.kr/entry/linux200807051

서버를 설치하면 항상 톰캣을 기본으로 깔았었다. 톰캣이야 맨날 보는 거니까 다루기는 편했지만... 상용서버에서도 이 녀석이 잘 견뎌주는지는 항상 의문이었다. 그렇다고, 웹로직을 살수도 없고

연휴를 맞이하여, 전부터 관심있던 글래스피쉬(GlassFish)를 설치해봤다. 혹시 이녀석이라면 비싼거 안사고도 웬만큼 견디는 환경을 구축할수 있지 않을까.

여차저차해서 설치에 성공, db 컨넥션 만들고, 서블릿과 jsp 에서 데이터를 집어와봤다.

스트레스를 해본다. ab 가 만능은 아니지만, 스트레스 테스트는 언제나 ab로..

[code]ab -kc4 -t30 http://test_server_ip:8080/TestS[/code]

해봤다. 약간 실망스러운 것이, 톰캣이나 글래스피쉬나 속도/실패비율이 크게 다르지 않았다. EJB3라던가.. 모니터링이라던가.. 따위따위가 별로 필요없고 서블릿만 쓰는 거라면 글래스피쉬의 도입효과는 크지 않을 것 같다. 역시 용도가 다른 것일뿐, 톰캣이 만들어온 안정적인 서블릿 컨테이너라는 영역은 다른 녀석들 (그리즐리나..) 에 비해 떨어지지 않았다.

사실 속도보다는 다른 측면에서 호감이 가게 되었다. 넷빈즈에서 개발하고 디플로이 하는 과정같은 것들을 한번 겪고나니 이거 없이 어떻게 개발하나 싶은 생각이 들었다. (톰캣도 그런 식으로 개발할 수 있다. 다들 이런 식으로 개발하고 있었는데, 나는 이제서야 .. 촌스럽게 ㅜㅜ )

그리고, EJB3 나 모니터링 따위도 다시한번 고민하게 된다. (공부해야하나.. 라고)


열시간 정도 걸린 타이핑과 구글링끝에 찾아낸 간단 자료.

http://www.youtube.com/watch?v=CKuoDm6bqRM
http://nigibox.wordpress.com/2009/10/03/glassfish-apache-on-debian/
http://netbeans.org/kb/docs/javaee/javaee-gettingstarted-screencast.html

[code]
su - glassfish
wget http://download.java.net/glassfish/v3/release/glassfish-v3.zip
glassfish@s:/opt/glassfish$ unzip glassfish-v3.zip
glassfish@s:/opt/glassfish$ mv glassfishv3/* /opt/glassfish/
cd /opt/glassfish/
bin/asadmin start-domain domain1
[/code]


관련자료:
* 글래스 피쉬의 앞단인 그리즐리(Grizzly)가 NIO에 기반하기 때문에 톰캣보다 엄청 많은 접속을 처리할 수 있다는 주장 : http://blogs.sun.com/thea...., 하지만 뒷단에는 어차피 서블릿 컨테이너일뿐, 앞단은.. nginx가 있잖아?
* 넷빈즈에서 그루비 스크립트 돌리는 동영상 강의 : http://www.screenca...51
* 넷빈즈에서 스칼라 돌리기 : http://wiki.netbeans.org/... (다음버전에서는 더 쉽게 지원될 듯)
* 글래스피쉬는 서블릿 스펙 3.0을 지원한다. 파일 업로드가 스펙에 들어있는 듯. http://www.ibm.com/...

debian 5 에 tomcat 6.0.20 을 설치하고 테스트용 JSP를 작성해보았다. 기본 설정으로는 JDBC 연결이 되지 않는다.


먼저 설치 확인하고 톰캣에 mysql jar 연결
[code]
apt-get install libmysql-java tomcat6 tomcat-common
cd /usr/share/tomcat6/lib
ln -s /usr/share/java/mysql.jar
[/code]


/etc/tomcat6/server.xml 수정
[code]
    <GlobalNamingResources>
      ...
    <Resource name="jdbc/mydbname" auth="Container"
          type="javax.sql.DataSource"
          username="mysql_loginid" password="mysql_pass"
          driverClassName="com.mysql.jdbc.Driver"
          url="jdbc:mysql://server_ip:3306/databasename" />
      ...
    </GlobalNamingResources>[/code]
(removeAbandoned 따위 인자는 안적는게 좋네요.. ㅜㅜ)



/etc/tomcat6/context.xml 파일 수정
[code]
<ResourceLink global="jdbc/mydbname"
   name="jdbc/mydbname" type="javax.sql.DataSource" /> [/code] (만약... 호스트나 어플리케이션에 특화시키려면..
/etc/tomcat6/Catalina/[hostname]/[appname].xml 혹은 /etc/tomcat6/Catalina/[hostname]/ROOT.xml
에 적어야한다.)


자바 소스에서 사용할 때는
[code]
Context ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/mydbname");
Connection conn = ds.getConnection();
Statement stmt = conn.createStatement();
ResultSet rst = stmt.executeQuery("select ...");
while(rst.next()) { ... }
[/code]





다 했는데.. 이런 오류가 난다면,
(Could not create connection to database server. Attempted reconnect 3 times. Giving up.)

/etc/tomcat6/policy.d/04webapps.policy 에 다음 코드를 추가한다.
[code] permission java.net.SocketPermission "데이터베이스서버_아이피:3306", "connect";[/code]


검색에 걸리게 하기 위해 설정을 제대로 안했을 때 나타나는 오류를 적어둔다.
* Name jdbc is not bound in this Context
* Cannot create JDBC driver of class '' for connect URL 'null'
* Cannot load JDBC driver class 'com.mysql.jdbc.Driver'