Home - SymmetricDSFast & Flexible Database Replication SymmetricDS is open source database replication software that focuses on features and cross platform compatibility.
PostgreSQL JDBCドライバのタイムアウト設定 - n-agetsumaの日記
OracleのJDBCドライバと同様に、PostgreSQLのJDBCドライバにも同様のタイムアウト設定が用意されています。@yamadamnさんがWebLogicServer + Oracle JDBC向けにまとめた資料Oracle JDBCドライバプロパティの活用を参考に、WildFly + PostgreSQL版のタイムアウト設定を以下にまとめます。 データベース接続時のタイムアウト PostgreSQLのデータベース接続時のタイムアウトには2種類のパラメータがあります。いずれもデフォルトは未設定で、Javaのレイヤではタイムアウトの設定はされず、NW障害時やDBハングアップ時にはOSのTCP接続タイムアウトまで待ちます。 loginTimeout=<秒> このタイムアウト設定はTCP接続のタイムアウトではなく、ログイン処理全体のタイムアウトを示します。PostgreSQLへのログイ
100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
JDBC setFetchSize() ではまった話 | TECHSCORE BLOG | TECHSCORE BLOG
JDBCのsetFetchSizeメソッドはご存知でしょうか？ 通常、クエリの結果はResultSetにすべてロードされます。このため、大量のレコードを取得するようなクエリではOutOfMemoryErrorが発生してしまいます。 このような場合に有効なのがsetFetchSizeです。 たとえば、クエリ発行の前にsetFetchSize(1000)とすると、1000件ずつResultSetにとりこまれるようになり、OutOfMemoryErrorを回避することが可能です。 （もちろん、搭載メモリ量、１レコードあたりのサイズによります！） しかし、ここに罠がありました。。。 setFetchSizeを使用しているにもかかわらず、全件がResultSetにロードされてしまう場合があるのです。 JDBCドライバごとにsetFetchSizeの挙動がかなり違っているので、はまりどころです。 今回
DBのTCPプロトコルとJDBC
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
PostgreSQL 互換 Amazon Auroraの高速フェイルオーバーを試してみた | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 先日正式リリースとなったPostgreSQL 互換 Amazon Auroraですが、Auroraの特徴の一つである高速なフェイルオーバーを試してみました。 高速フェイルオーバー ドキュメントにPostgreSQL互換Auroraの高速フェイルオーバーについて記述があります。PostgreSQL JDBC Driverを使用します。urlを複数記述して、targetServerTypeでmasterを指定するとWriterを高速にフェイルオーバーできます。 注意点として、targetServerTypeの指定ではコネクションのオープン時に判断されます。MySQL互換Auroraで使用されるMariaDB Connector/Jの場合はステートメントで判断しています。同じAurora用のフェイルオーバーでも挙動が異なるので注意して下さい。
コネクションプーリングの効果を実測してみる - n-agetsumaの日記
Java EE アプリケーションサーバを使うとどの製品にもDBコネクションプーリング機能が付いている。DB接続の再接続にはコストがかかることがこの機能の動機だが、いったいどれくらいの『コスト』なのか。あまり実データを見たことないので、実際に測ってみる。 テスト環境 コストを実感しやすいように、DBには接続ごとに対応した子プロセスをfork()するPostgreSQLを使ってみる。 Mac OS X (Core i5 1.7GHz) OracleJDK 1.7.0_51 PostgreSQL 9.3 PostgreSQL JDBC Driver 9.3-1100-jdbc41 Commons DBCP 1.4 テスト内容 10多重で1回、100回、1000回、10000回の新規接続して SELECT 1 を投げるプログラムを実行する。DBCPを使ったコネクションプーリングの有無で性能を比較す
Javaトラブルに備えよう #jjug_ccc #ccc_h2
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「PostgreSQL」データベースをGUI管理できるWebアプリ「PostgreSQL Studio」が公開