jConnect と iAnywhere (現SQL Anywhere) JDBC ドライバーの違い

この記事のオリジナルは、Glenn Paulley が sybase.com に 2009 年 10 月に掲載したもので、この中で Glenn は jConnect と SQL Anywhere JDBC ドライバーの違いについて述べています。

パート 1 のブログ記事でも追記しましたが、versions 12 と 16 の SQL Anywhere JDBC ドライバーでは、 JDBC 4.0 をサポートしています。
また、最新の jConnect のバージョンは 7.07 で、こちらも JDBC 4.0 をサポートしています。

パート1 のブログ記事では、SQL Anywhere で使用する場合の jConnect JDBC ドライバーと iAnywhere (現SQL Anywhere) JDBC ドライバーの違いを簡単に述べました。

また、ホワイトペーパーでは、この 2 つのドライバーのアーキテクチャー的な違いについてまとめています。

jConnect も、iAnywhere (現SQL Anywhere) JDBC ドライバーも JDBC 3.0　をサポートしています。
jConnect は、「pure Java」のソリューション (Type 4 JDBC ドライバー）で、iAnywhere (現SQL Anywhere) JDBC ドライバーは、Type 1 ドライバーです。
これは、iAnywhere (現SQL Anywhere) JDBC ドライバーが SQL Anywhere ODBC ドライバーに依存しているからで、SQL Anywhere ODBC ドライバーが適切にインストールされている必要があります。

「pure Java」のソリューションの方が、良い/速い/より堅牢であると言われることもあることから、 jConnect の方が iAnywhere (現SQL Anywhere) Type 1 ドライバーよりも良いように思われますが、深く知るにつれて、2つのソリューションの間に (1) メモリーの管理、(2) TDS ワイヤプロトコルの使用、(3) セマンティクスが違う、という大きな違いがあることを認識されると思います。
ここでは、それらについて説明します。

メモリー管理

pure Java ソリューションでは、

全てのオブジェクトは、Java 仮想マシンが管理します。
Java ガベージコレクションは、自動的にクリーニングを実施するので、アプリケーションプログラマーは、不明瞭なオブジェクト、メモリーリーク、使用中のオブジェクトの消失、などについて悩む必要はありません。

残念ながら、pure Java のソリューションの弱点は、結局同じで、メモリー管理です。

アプリケーションプログラマーは、オブジェクトのライフスパンに対して、ほとんど、あるいは全くコントロールすることができません。
さらに、プログラマーは、ガーベージコレクションも、効果的にコントロールすることができません。ガーベージコレクションは、重要な時でも Kick inすることができてしまうため、再現不可能なパフォーマンス問題がランダムに発生してしまいます。

そのため、iAnywhere (現SQL Anywhere)　JDBC ドライバーのようなハイブリッドのソリューションにおける最も重要な利点は、メモリー管理です。

プログラマーは、non-Java のオブジェクトに対してフルにコントロールを維持できます。
ガーベージコレクションは、Java オブジェクトへの non-Java リファレンスによって妨げるあるいは延期することが可能です。

しかしながら、pure Java であるがゆえ、ハイブリッドのソリューションで最も不利な点は、ご想像のとおり、これもまた、メモリー管理です。ハイブリッドのソリューションでは、non-Java オブジェクトは、明示的に管理する必要があります。

プログラムエラーは、良くてもメモリーリーク、メモリー破損、最悪の場合には、GPF になります。
もし Java オブジェクトリファレンスが、あまりにも長く保持される場合には、Java ガーベージコレクションは Kick in しません。

続きはこちら：jConnect と iAnywhere (現SQL Anywhere) JDBC ドライバーの違い – パート2

SAPの SAP SQLAnywhere製品ページはこちら