EJB programming & troubleshooting: Stateful session bean timeout

  1. Stateful session bean timeout (3 messages)


    I have a stateful session bean used in a Remote Iterator, I've got a jdbc connection open inside so I need to release it. So I wan't to release my bean data after 20mn of inactivity (behavior like the HttpSession object).

    Any idea ?

  2. Yes, this is possible

    Check your app. server docs -- there defnitely should be a set of options that let you control SFSB lifecycle policy including time after what SFSB should be passivated. Then you can use hook methods to clean-up resources. Anyway, you have to clean-up JDBC resources before passivation since they are not serializable.

    P.S. Btw, your design is not very (if ever) scalable as any design with SFSB involved.

  3. P.S. Btw, your design is not very (if ever) scalable as any design with SFSB involved.

    Can you explain more ?

  4. Can you explain more ?

    Sure. My pardons, if arguments are not very objective, but I'm personally avoid using SFSB.

    1. They have state, so they must have unique per-client instance.
    2. App. server cache for SFSB is limited. Probably, it is big enough, but there is always a limit.
    3. According to 1 & 2 server has to passivate SFSB from time to time. Often this means serialization to disk file. Obviously, this is comparably slow process. And SFSB tend to have quite large / complex internal structure to describe state -- otherwise, what it is for?
    4. In cluster server has to synchronize state of SFSB. Slow as previous + cost of calls via network.
    5. Even if there is a certain "exit" point in your SFSB, it is not called always. For example, client closes his browser without logout. Nothing passed to web tier. So nothing could force SFSB removal. It stays in memory until timeout. As well as all pre-allocated resources. And it is more heavyweight comparing to HttpSession.

    Now consider all the above in regard to heavy load scenario. Server will start juggling SFSB to/from disk via serialization. Probably, broadcasting updates to other cluster nodes as well. Will be this a top of performance?

    Obvious, that "Add more memory!" panacea could be applied here. But I'm not sure that will help much with clustering.

    Personally, I'm using following SFSB-replacement receipts:
    1. If you have web tier, maintain state in HttpSession
    2. If you have rich client, maintain state on client
    3. If other EJB have to access state and state getting very complicated -- then make it persistent, i.e. place in database or other storage. It's much simpler to clean-up storage on regular intervals via quite straightforward batch procedures rather then orchestrate all that SFSB jazz.

    More on this topic: Stateful Session EJBs: Beasts of Burden and the follow-up An attack on stateful session beans