How EJBs are used in the server


EJB programming & troubleshooting: How EJBs are used in the server

  1. How EJBs are used in the server (3 messages)

    Hi guys. Can you give me an opinion on this one:

    Terms used:
    SLSB, SFSB, EB - the bean instance
    EJBObject - the remote/local stub (for simplicity's sake, same as the interface)
    EJBHome - the remote/local home stub (for simplicity's sake, same as the interface)
    pool - where SLSB and EBs are placed when they have no related EJBObject
    cache - where EBs are placed when they hold a row of record

    Scenario I: Stateless Session Beans
    When you start your server it will create as many SLSB objects in its pool as specified in your deployment descriptor. These SLSBs are not tied to any EJBObjects yet.

    public class A {

    public void mA(){

    InitialContext iCtx = ...
    MyEJBHome home = (MyEJBHome) iCtx.lookup(...);
    MyEJB ejbA = home.create();
    ejbA.remove(); <-- not needed


    When your client calls the create method of MyEJBHome, the server will give you a MyEJB object. When you call a method on this object, e.g., subtract(), the server will pull out one of the SLSBs in the pool and pass the request to it, When the request finishes, the SLSB goes back to the pool. When you call a second method on that object again, the server will pull out again one of the SLSBs in the pool, and so forth and so on. When an SLSB (and entity beans for that matter) goes back to the pool, it loses any instance variables it may have. And each SLSB can be used by multiple clients.

    This is the reason why SLSBs cannot maintain a user session. You don't have to worry about Out-Of-Memory erros here as the container does a very good job on this one. This is also the main reason why many companies/programmers prefer SLSB over SFSB.

    Scenario II: Stateful Session Beans
    For SFSB, each client will be allocated one SFSB. Every method call on the EJBObject will be routed to the same SFSB everytime. This makes it possible for the bean to handle state. It is imperative for SFSB's to have the remove() method called because there is no way for the server to know that an SFSB is not used anymore and hence cannot be garbage collected. This is different from regular objects where the JVM know when an object is not being referenced anymore. If you don't call the remove() method, more and more SFSBs will accumulate in the server until some gets passivated. This happens even if you don't have any references to the SFSB in you clients anymore.

    Scenario III: Entity Beans
    Same as SLSBs, the server creates as many EBs in the pool as specified in your deployment descriptor. When a client requests an entity bean (either via create(...) or findXXX(...) methods) the server takes out one EB from the pool, assigns the corresponding record to it and then places it in the cache. If multiple clients request for the same record, the server will assign different EBs for each. You don't have to call the remove() method on the EJBObject for this bean, well, unless you really want to delete the record. The beans will stay in the cache until the max-beans-in-cache limit is reached, then, the beans that are LRU will be passivated.

    Somehow, out-of-memory error occurs when the server cannot passivate anymore beans and more beans need to be created.



    Threaded Messages (3)

  2. How EJBs are used in the server[ Go to top ]

    you have a good grasp of what is going on in the EJB container. Some points need clarification.

    Scenario I:
    When placed back into the pool, SLSBs variables are not 'lost'. They retain the current values. When a bean is given to another client these variables may need to be reinitialised. Typically variables in SLSBs hold values that are overwritten in each business method. Longer term objects such as environment values, JNDI contexts and bean homes may also be kept in SLSB variables.

    Scenario II:
    Not calling remove() on SFSBs can cause performance problems due to beans being passivated however unused beans cannot exist forever. Containers normally have a session timeout setting and will destroy SFSBs after the timeout expires. Session timeout values are specified in a vendor specific way. For example, with WebLogic you specify the timeout value in the WebLogic deployment descriptor.

    Scenario III:
    Containers handle concurrent access to EBs in different ways. For example, with WebLogic behaviour is dependent on the beans concurreny strategy setting. If the database is responsible for locking then you get the behaviour you describe. Concurrent calls will cause multiple bean instances to load from the same row. In this situation it is important to select the correct isolation level for your database so that concurrent updates are not lost and deadlocks are avoided.

    WebLogic can also have a concurrency strategy of 'exclusive'. When set to exclusive the container performs concurrency locking and only a single bean is loaded from the row. The container blocks concurrent access until transactions complete.

    Hope this helps,
  3. How EJBs are used in the server[ Go to top ]

    Are SLSBs really pooled (instance-wise, I mean)? A thread pool on a single instance would be sufficient, no?
  4. How EJBs are used in the server[ Go to top ]

    SLSBs are pooled in WebLogic 6.1. A single instance with a thread pool won't work because SLSBs can have instance variables and the spec guarantees that beans do not have to be written in a thread safe manner.