Stateful session bean evicted vs. pooled?


EJB design: Stateful session bean evicted vs. pooled?

  1. Stateful session bean evicted vs. pooled? (3 messages)

    I have a fundemental question about EJB.
    Why stateful session bean got evicted after passivation?
    Since stateful session bean and entity bean are both
    contain state, why entity bean can be pooled and stateful
    bean can't?Or the overhead of creating new object vs. pooling is neligable?

  2. The architecture shows that Stateful session beans are activating thru a pool after passivating ,So engine knows that when to activate Stateful but in case of EB this maintains a cache and persist in database ,So u have to take this into consideration.
                   If req more then mail to me
  3. Which source are you looking at?

    My question is why SFSB adopting this architecture:
    1 client 1 bean instance, the number of bean instances keeps growing and growing, until a client comes in and server doesn't have more meory to create a new bean instance, an existing bean is choosen and got evicted.

    But not the following architecture:
    m client n bean insance (m>n), the container dynamically
    keep a pool of bean instances, the container will do method level load balances...of course there is an overhead of
    passivation and activation for SFSB.

    Isn't the second approach more scalable?

    Probably approach 1 is only a conceptial model, and vendor
    is free to do the implementation using approach 2?
    But when I look at the weblogic document, their implementation is using approach 1.

    Do I miss something?

  4. Stateful session bean evicted vs. pooled?[ Go to top ]

    Stateful session beans maintain client conversational state, and each has to have a 1:1 relationship with the client. They cannot be pooled. Entity beans do you maintain client state - they represent persistent data which can be shared among many clients.