いくつかのデータベースクエリを作成するために使用されるステートフルBeanがあります。最初に呼び出すメソッドで接続を開きますが、EJBクライアントがステートフルBeanで実際に実行された後でのみ、接続を閉じたいと思います。データベース接続を閉じるロジックを@PreDestroyメソッドに入れることができると思いました。
これは機能しているようですが、その影響について興味があります。具体的には、EJBセッションはいつ完了しますか？これはコンテナ管理のトランザクションであるため、EJBクライアントメソッドが完了すると、EJBトランザクションも完了すると思います。具体的には、PreDestroyメソッドはいつ呼び出されますか？トランザクションはまだありますか？それとも、すでにコミットしてプールに戻しましたか？ありがとう！
以下は仕様からの抜粋であり、ステートフルセッションBeanのライフサイクルを明確にする可能性があります。
ライフサイクルの最後に、クライアントは@Removeという注釈の付いたメソッドを呼び出し、EJBコンテナーは@PreDestroyという注釈の付いたメソッドを呼び出します（存在する場合）。これで、Beanのインスタンスはガベージコレクションの準備が整いました。
セッションBeanのPostConstructまたはPreDestroyライフサイクルコールバックインターセプターメソッド内でデータベース操作を実行し、操作がクライアントのトランザクションの一部であると想定するのは誤りです。PostConstructメソッドとPreDestroyメソッドは、トランザクション属性によって制御されません。これらのメソッドでロールバックを処理すると、セッションインスタンスの状態図が非常に複雑になるためです。
PreDestroyメソッドは、指定されていないトランザクションおよびセキュリティコンテキストで呼び出されます。
PrePassivateコールバック通知は、インスタンスを非アクティブ化するコンテナの意図を通知します。PostActivate通知は、再アクティブ化されたばかりのインスタンスに通知します。コンテナは、パッシブ化されたときにステートフルセッションBeanインスタンスの会話状態を自動的に維持するため、これらの通知はほとんどのセッションBeanでは必要ありません。それらの目的は、ステートフルセッションBeanが、インスタンスのパッシベーションの前に閉じられ、インスタンスのアクティブ化中に再度開かれる必要があるオープンリソースを維持できるようにすることです。