Discussions

EJB design: Instance pooling

Bookmark and Share Get thread feed

  1. Instance pooling (6 messages)

    • Posted by: Raji Sunder
    • Posted on: January 05 2005 11:42 EST
    Hi,

    Can somebody tell me how instance pooling is achieved in Entity beans, Stateless and Stateful session bean??

    Thx
    Reply to this

    Threaded Messages (6)

  2. Instance pooling[ Go to top ]

    EJB spec expects EJB containers to implement instance pooling, but does not specify HOW they should do it. It only defines the EJB's life-cycle.
    Thus, every container might have a different way to implement instance pooling.
    The only thing that IS specified by EJB is that a compliant container should mantain a pool of instances, and that those instances can be in different states: POOLED, READY (and perhaps others, which i don't remember). POOLED instances are uses to perform Home operations: create, find, etcétera. READY instances are instances in use by a client.
    Check the spec for details.

    Regards,
    Martin
    Reply to this Reply to original

  3. Instance poolings[ Go to top ]

    Thanx a lot..
    I've one more doubt.
    Entity beans doesn't support Bean Managed Transactions? Y is it so?
    Reply to this Reply to original

  4. Instance poolings[ Go to top ]

    Hmmm, don't remember. Educated guess: they do. I'm too lazy to check the specs right now, sorry... it's really hot in here and my fan is a joke. ;)

    Regards,
    Martin
    Reply to this Reply to original

  5. Entity beans should use only container managed transactions. y??[ Go to top ]

    I got the answer for the above question.

    A transaction spans ejbLoad(), business methods and finally ejbStore, so that if one of the operations fail, all of them fail.

    If we use bean managed transactions, we would write code for the transactions ie.. begin() and commit() methods. It would be like
    begin(); ejbLoad(); business methods; ejbLoad(); commit or rollback; But the problem is even though we write the code for ejbLoad() and ejbStore(), these methods are called by the container. So, the bean cannot enforce that the conatiner calls the methods in the above order. since we cannot guarantee of the order, sometims it may happen that the transaction never gets completed. hence it is illegal to use bean managed transactions.
    Reply to this Reply to original

  6. Entity beans should use only container managed transactions. y??[ Go to top ]

    hence it is illegal to use bean managed transactions.

    Is this your conclusion, or a quote from the spec? There's no conceptual difference between the lifecycle methods of an Entity EJB an a Session EJB. All of them are called by the container, when the container wants. But you CAN rely on the spec, in the sense that the order IS prescribed. So, you know for sure when you can call the begin() and commit() methods.

    Cheers,
    Martin
    Reply to this Reply to original

  7. Instance pooling[ Go to top ]

    I couldn't find anything relevant to this topic from the Spec. This is what i gathered after reading "Mastering Enterprsie Java Beans" by Ed Roman. Entity beans load and store data on every transaction and not on every method call. He says that for entity beans, since ejbLoad and ejbStore are called by the container, beans have no control over the above methods. But for session beans,bean can load db data, perform operations and store the data in a single transaction. I guess that is why it is said that bean managed transaction is possible in session beans.
    Reply to this Reply to original