Discussions

EJB programming & troubleshooting: Any problems if I don't remove a stateless session bean?

  1. Hi,

    I'm just wondering what happens if I don't remove a
    stateless session bean explicitly by invoking remove() in
    remote interface.

    If I invoke remove(), that instance may or may not be be
    destroyed by the container, right? If so, why should I
    bother about removing it in the first place?

    In the same way, I don't have any control over the number
    of entity bean instances in the container, right?

    Thanks and regards,
    Choudary.
  2. to ur first question:
    "I'm just wondering what happens if I don't remove a
    stateless session bean explicitly by invoking remove() in
    remote interface.

    If I invoke remove(), that instance may or may not be be
    destroyed by the container, right? If so, why should I
    bother about removing it in the first place? "

    I just met the same problem,and I found a instance of a EJB may be still exist in the container even if I have used remove() to it.This can cause a big problem sometime.I defined some attributes of my EJB, and give values to them when I call the EJB the first time,then used remove(),but I fount it show the same values when I call the EJB the second time.
    I think it's safe for u invoke remove(), we don't know what the container do exactly.
    and be careful to the attributes of a EJB!
  3. I found a simillar problem on UNIX .On NT there is no problem. But if i dont remove on solaris after sometime i am getting peer reset kind of messsages . Which means the ejb is active till that time.
  4. I guess, you should go thru the ejbspec rather carefully here. the point to be taken is: calling remove() DOESN'T necessarily mean the beans has been taken off THE CONTAINER. the point is that there is no synchronization between the remove you call and that called by the container. it is similar to the ejbcreate method, rather. calling ejbcreate() doesn't necessarily mean a new bean instance is created. one from the pool might be assigned to the ejbobject.
    as far as your second question is concerned in weblogic atleast there is a way to limit the number of stateful bean instances to be floating around. i am not sure about the entity bean case. i will check it out
    regards
    vijay
  5. Yes, there is a way to limit the number of beans in the container - in the deployment descriptors:<br>
    <max-beans-in-cache>XX</max-beans-in-cache> in Weblogic
  6. Just as a point to all those who may be reading this, the container takes care of "removing" session beans, you do not have to explicitly call remove for a session bean. If you do call remove for a session bean, it does not mean it doesn't really hang around in the container, it could be cached, that is why you should not put any initialization code into a session bean's create, if you need to initialize a session bean I would suggest creating an initialization method that you call once you create the session bean, this way you can guarantee a clean session bean.

    As a final note, calling remove() on an Entity bean will call the entity beans ejbRemove() method, which should remove the data item it is pointing to in the data store. So it should be equivalant to doing a delete sql command.

    rich
  7. So everyone agrees that we don't need to remove() a
    stateless session bean, right?