かなりながーいエントリになる予定なので,結論だけ最初に書くとこんな感じ. この話題については自分も あとで書く と言って書いてなかったので書いてみますよ。2006年の下期にもなってコネクションプーリングかよというツッコミもありそうですが、あとで書くといったら書くの。あとで読むといったら読む。 普通「コネクションプーリング」と言ったら、主に二つの役割があると思います。話を簡単にするためにウェブアプリケーションに限定して言及します。 ウェブアプリケーションから DB への接続を開けっ放しにして、接続に必要とされるオーバーヘッドをカットして双方の負荷を下げる。 ウェブアプリケーションと DB への接続を「使いまわす」ことで、同時接続本数を節約する。 というもの。 mod_perl で DB と接続維持するとコネクション数増えて云々という話は主に前者のみについての話になります。Apache::DB
これまで eclipse で製造していたWebアプリケーションを、Profiler にかけるため、NetBeans に必死で移行。その結果、DataSource でコケる。 javax.servlet.ServletException: Cannot create JDBC driver of class '' for connect URL 'null' やっぱり設定をコピペするだけでは、動いてくれないらしい。ううう。 原因は Tomcat にあり。これまで Tomcat5.0 で開発していたのだけれども、NetBeans5.0 にバンドルされていたのは Tomcat5.5 だった。「0.5くらいなら大丈夫だべ」と思って強気で攻めたんだけど、だいぶ違うみたいでして。トム猫さん、頼むよ。 具体的には、JNDI リソースの指定方法が変わった。設定は、<ResourceParams> タグを使
【第3話】Tomcatの持つコネクションプール「DBCP」 ■netstatコマンドによる確認 あるプログラムがソケットを使用してほかのプログラムと通信している場合、netstatコマンドを使用してソケットの状態を確認するといろいろなことが分かる。 早速、netstatでDBコネクションの状態を見てみると、確立済み(ESTABLISHED)状態のコネクションが、DBCPに設定している最大コネクション数と同じ数だけ存在した。Tomcatの設定を確認してみると、DBCPの最大コネクション数はTomcatの最大スレッド数と同じ値に設定してあった。つまり、スレッドが同時に複数のコネクションを使用しない限りコネクションが不足することはない。 ■リーダー「同時に1つのコネクションしか使わないはず」 アプリケーション開発のリーダーに確認したところ、「アプリケーションは同時に1つのコネクションしか使わない
Author : snbhsmt at ps dot ksky dot ne dot jp Last-Modified : 2004/06/29 16:00 JST Commons DBCP について Commons DBCP (Database Connection Pool API) は、JDBC を利用して DB との接続の プーリング機能を提供する。 実際のプーリング機能は Jakarta Commons Pool API を利用している。 詳細は、アーカイブ内の README.txt や docs/ 内のソース、 あるいは以下のページ等を参照。 Jakarta Commons DBCP Home (日本語訳) http://jakarta.terra-intl.com/commons/dbcp.html Jakarta Commons DBCP 1.0
I'm using the BasicDataSource from apache commons dbcp in a struts application to connect to an oracle 8.1 dbs. If the dbs is restarted (what happens pretty rarely, but the app should run for months without restart) I'm getting a broken pipe SQLException. Apparently the BasicDataSource doesn't reconnect when needed. Other databases have some parameter like autoReconnect=true, but I haven't found
Commons DBCP は、データベースのコネクション・プーリングを扱うライブラリです。 Tomcat で標準採用されています。 動作説明 動作を簡単に説明します。 クライアントから接続要求が発生した場合 … getConnection() 1. DBCPは、プール内に空き接続があるか確認 2. あればそれを返す。この時その接続は アクティブ となる 3. プール内に空き接続が無ければ、新たに接続を作って返す クライアントから切断要求が発生した場合 … conn.close() 1. 切断要求のあった接続をプール内に保管する。この時その接続は アイドル となる 2. もしプール内に maxIdle 以上の接続が溜まったら、それ以上にならないように接続を削除する 接続監視スレッド DBCPには接続監視スレッドというものが存在します。 これは一定時間毎にプール内のアイドル接続をチェックするも
【トラブル大捜査線】失われたコネクションを追え!:現場から学ぶWebアプリ開発のトラブルハック(7)(3/3 ページ) 【最終話】それが、トラブルシューティング屋の務め クローズ漏れの個所も大体の見当が付いたので、アプリケーション開発チームに確認・修正を依頼した。 アプリケーションが直るまでの間、removeAbandonedを付けたままで負荷試験を継続することにした。目的はremoveAbandonedのオーバヘッドを測定することである。logAbandonedを指定しなければstackTraceは生成されない。そのため、ある程度の性能は出るように思われた。 ■removeAbandonedの同期化 しかし、実際に測定してみたところ、思ったように性能は出なかった。CPUがほとんど使い切れなかったのだ。 ここまできたら、ついでに解析してしまうのが、トラブルシューティング屋の務めだろう。負荷
以前のバージョンのOracleでは、*.zipとしてドライバが提供されていたが、Tomcatで利用できるのは、*.jarのみ。 $CATALINA_HOME/common/lib にインストールする。 *.zip は *.jarにリネームする Server.xmlの設定 JNDI DataSource を $CATALINA_HOME/conf/server.xml に記述する。 ContextタグをHostタグの中に記述 <Context path="/myoracle" docBase="DBTest" debug="5" reloadable="true" crossContext="true"> <!-- maxActive: Maximum number of dB connections in pool. Make sure you configure your mysqld
10年ぶりにブログを更新。最近は、twitter、facebookがメインになっています。 結局、10年間、同じところで残業代付きの人月契約を続けています。途中で契約金額を上げてもらいました。フロントエンド技術者として、いろいろな開発をしました。 複雑なSPAをFlashで何個か Swift/iOSとKotlin/Androidの同時開発を二つ 大規模SPAをVue.jsとCypressで 複雑なSPAをTypeScript/Reactで何個か (上記と、私が加入前の)フロントのメンテナンス Flashで開発したシステムを、Reactでリプレースするのも担当したので、システムの開始と終了に携われたのは、感慨深いものがあります。 フロントの開発が一通り終わり、今後はサーバサイドも一緒に見て欲しいと言われています。元々、サーバサイド技術者だった時もあるので、見ることは出来ますが、UIのほうが好
以下、設定メモ。 必要になるのは、PostgresSQLのjdbcドライバ。 一応、postgresql-8.1-407.jdbc3.jarをダウンロード。 このファイルは、$CATALINA_HOME\common\lib内に入れておく。 これだけでOK。 あとは、server.xmlの内容とweb.xmlの内容を変更。 サイト名:site データベース名:appdb DBユーザ:scot DBパスワード:pass DBホスト:192.168.0.000 1.server.xmlの記述 Context部分にResourceプロパティを追加。 <Context path="/site" docBase="C:\xxx\site" debug="0" reloadable="true" crossContext="true"> <Resource name="jdbc/postgres" a
データベースの接続情報は、開発環境から実行環境への移行や、アプリケーションをパッケージとして配布する際に変更する必要があります。この情報は大概「.jsp」ファイルや「.java」ファイルに分散して記述されており、実行環境への移行やパッケージとしての配布の際に、修正漏れや間違いを引き起こしやすい要因といえるでしょう。 この問題を解決する方法の1つに、JNDI(Java Naming and Directory Interface)を使って環境に依存する(かつアプリケーション内で共通して使用する)情報をアプリケーション上で一元的に管理するというテクニックがあります。JNDIを採用することで、個々の「.jsp」「.java」ファイルにいちいち接続情報を記述する必要はなくなりますし、接続先のデータベースに変更があった場合にも容易に変更が可能となります。もちろん、「.java」ファイルのコンパイルな
Tomcat のコネクションプールは Commons-dbcp と Commons-pool によって実現されています。jar は CATALINA_HOME/common/lib にあります。 設定は CATALINA_HOME/conf/server.xml で行います。 Oracle の場合の XML の設定例と Java のソース記述例を書きます。 server.xml 記述例(5.0まで) <Context path="/test" reloadable="false" docBase="test.war" autoDeploy="true"> <Resource name="jdbc/oracle" auth="Container" type="javax.sql.DataSource"/> <ResourceParams name="jdbc/oracle"> <parame
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く