私のチームは、運用の展開の一環としてTomcatにApache Derbyを組み込むことを検討しており、導入の容易さが主な動機となっています。誰もがこの計画に重大な欠点を示唆することはできますか？データベースには、同時に2つ、または3つのWebアプリケーションが同時にアクセスします。最初は、いずれか1つのテーブル内のエントリの最大数が10,000マークの近くにあると予測されますが、これは増加する可能性があります。何かアドバイスをいただきました。誰でもサーブレットコンテナに埋め込まれたデータベースの本番運用に不利な点を提案できますか？
私にとってダービーの理想的な使用のようなサウンドです！ Derbyは、組み込み、容易に配置できるように設計されています。ちょっと複雑なのは、複数のWebアプリケーションを使用することだけです。各Tomcat Webアプリケーションは別々のクラスローダーインスタンスなので、Derbyの複数の独立したクライアントアプリケーションのように見えるため、接続するときにDerby組み込みプロトコルではなくDerbyクライアント/サーバー接続プロトコルを使用する必要があります。つまり、http://db.apache.org/derby/docs/10.6/devguide/cdevdvlp96597.htmlの用語を使用するには、各Tomcat Webアプリケーションは別々のDerbyインスタンスです。
構成では、DerbyネットワークサーバーをWARファイルとしてパッケージ化した 'derby.war'を使用すると便利です。もう1つのWebアプリケーションとしてWARをTomcatインスタンスにパッケージ化し、それを使用してDerbyサーバーコードを管理し、各クライアントWebアプリケーションに接続します。 を参照してくださいhttp://db.apache.org/derby/docs/10.6/adminguide/cadminservlet98430.html
ありがとう、ブライアン、私たちはderby.warのアプローチでうまく行くかもしれません。サーバーレベルでデータソースを定義し、JNDIルックアップを使用してこのデータソースにアクセスすることを検討していました。http://db.apache.org/derby/integrate/DerbyTomcat5512JPetStor.htmlこのアプローチはどのように評価しますか？ – Joffer
私はそれが良いアプローチだと思います。しかし、JPetStore設定の最も重要な点は、アプリケーションが単一のTomcat Webアプリケーションとしてパッケージ化されていることです。元のメッセージでは、特に「2つの、または潜在的に3つのウェブアプリを同時に」と言いました。 Derbyにアクセスする単一のWebアプリケーションに保管できるのであれば、クライアント/サーバー構成よりも実質的に簡単なので、組み込み構成を使用してください。 –