私は CORBA と、IDL がインターフェイスをさまざまな言語にマップする方法を研究しています。オブジェクトがローカルで作成されないため、IDL インターフェイスでコンストラクターとデストラクタを記述できないことを読みました。
私の質問は：
IDL インターフェイスでデストラクタを指定しない場合、クライアントはどのようにオブジェクトを削除できますか? サーバーはオブジェクトの削除のみを担当しますか? CORBA はガベージ コレクションのメカニズム/仕様を提供しますか?それともサーバー側の言語がそれを行う責任がありますか? サーバーだけがオブジェクトを削除する責任がある場合、オブジェクトを削除する必要があることをどのように確認できますか? クライアントに ping を送信しますか?
私の教授の一人からの電子メールのリプレイ：
CORBA オブジェクトのすべてのライフサイクル管理は、オブジェクト アダプタによって行われます。CORBA には組み込みのガベージ コレクションはありません (ただし、非永続オブジェクトは、セッションが期限切れまたはハングしたとき、または時間制限が切れたときに非アクティブ化され、自動的に削除されます)。サーバント オブジェクトの登録解除メソッドの activate_object() を OA で (サーバー コードで) 明示的に呼び出して、OA がオブジェクトを適切に登録解除/割り当て解除するようにする必要があります (そのオブジェクトでまだ実行中のすべての呼び出しが終了するのを待った後)。
リモート コンストラクターの動作をシミュレートするには、(サーバー側の) ファクトリ オブジェクト (別の CORBA オブジェクト) を使用する必要があります。
リモート デストラクタの動作をシミュレートするために、ファクトリ オブジェクトは明示的な destroy メソッド (クライアントによって制御されるユーザー レベルのメモリ管理) を提供するか、ユーザー レベル (サーバーによって制御される) でガベージ コレクションの参照カウントを実装する場合があります。後者は、OA へのサーバント登録解除呼び出し (deactivate_object()) の順序が正しくなければならないため、注意が必要です。