(3) パフォーマンス
通常のメソッド呼び出しと比較して、CORBA経由の場合１オペレーション(メソッド)当たり約0.7秒程度の処理時間の低下が見られた。実際のGPME FLの処理時間は、CPUの混雑状態やODBMSのキャッシュの状態等により大きく(パフォーマンス試験での処理で2倍程度)変動するので、GPME FLのメソッド程度の粒度のサービスであれば、これをCORBA経由で利用することも十分現実的ではないかと考えられる。しかし、メソッドの内部処理自体をCORBAクライアントとして記述する程粒度を小さくした場合には問題となるかも知れない。
(4) GFにおけるGPME PMに対する排他制御の実現
GPMEのPMは、市販ODBMS(現在 ObjectStore)を利用して実装されており、永続的データ(PMデータ)へのアクセスに対する排他制御も市販ODBMSの機能を利用しており、GPMEとして公開されたインタフェースによる排他制御も基本的に市販ODBMSでの排他制御に沿ったものとなっている。
市販ODBMSでの排他制御は、通常データベースアクセスAPIを利用したプロセスを対象として行われる。例えば、あるプロセスがリードライトトランザクションを行っている場合、同じデータベースにアクセスしようとする他プロセスのリードライトトランザクションはブロックされる。
GFでは、PMへのアクセスをCORBA BUS上に提供するために、GFを利用しているクライアントプロセスと、実際にGPMEのPMアクセスAPIを呼び出している(すなわち市販ODBMSのAPIを呼び出している)プロセスは別なものとなっている。
CORBA仕様では、サーバープログラムの活性化モードとして、共有サーバー、非共有サーバー、メソッドごとのサーバー、永続サーバーと4種類がある。また、CORBAでは、同じサーバープログラムを複数のサービス名で登録できる。
プロトタイプでは、GFを共有サーバーとして複数のサービス名で登録した。こうして、クライアントがそれぞれ異なったサービス名でGFを利用するようにすれば、異なったGFサービスプロセスを経由してGPME PMへアクセスすることとなり、直接GPMEを利用した場合と同様な排他制御機能を提供することができた。
ただし、この場合同じサービス名でGFを利用するクライアントは同じGFサーバープロセスを共有することになり、複数のクライアントが不注意に同じGFサーバープロセスを利用した場合、PMを破壊することも考えられる。これらに対処するためにも、GFの状態(PMをオープンしているか、トランザクションは開始されているかなど)を問い合わせるサービスをGFに追加した方がよいとも考えられる。
逆に、これらのサービスを利用して整合性を維持するようにすれば、これまで一つのクラ
