-
1. Re: EJB's never being garbage collected
juha Aug 22, 2002 7:35 PM (in response to jasonb2)stateless, mdb, entities are pooled.. what type of EJB do you use?
-
2. Re: EJB's never being garbage collected
jasonb2 Aug 23, 2002 11:39 AM (in response to jasonb2)These are stareful session beans.
Oh yeah, I've tried it and get the same behavior in JBoss 2.4.6, 2.4.7 and 3.0.0.
Jason -
3. Re: EJB's never being garbage collected
jasonb2 Aug 23, 2002 12:25 PM (in response to jasonb2)Ok, I got my beans to garbage collect by explicitly calling remove() method of the remote object.
Is it supposed to be necessary to call remove()? I was under the impression that once the remote object has no more references on the client, it will be garbage collected, and as part of the finalization of that object it will signal the application server to release its reference. Is this not the case?
Thanks,
Jason Burton -
4. Re: EJB's never being garbage collected
juha Aug 23, 2002 3:24 PM (in response to jasonb2)It should garbage collect after the stateful bean has been passivated. Is that not the case?
-
5. Re: EJB's never being garbage collected
jasonb2 Aug 23, 2002 4:22 PM (in response to jasonb2)Yes, it does garbage collect after being passivated, but I was under the impression that when it is passivated, it is written to the disk so that it can be activated later.
I have EJBs that will never be used again, so I wouldn't want them passivated - I would want them removed altogether.
Does this not happen when the remote object is garbage collected on the client? It seems like I had seen the code for the finalize() method of a remote object stub for another app server. The finalize() method had a call to remove(), so it seemed like this would happen automatically. Is this not the case with JBoss?
Thanks,
Jason -
6. Re: EJB's never being garbage collected
adrian.brock Aug 23, 2002 4:57 PM (in response to jasonb2)Automatically calling remove() because the client
lost the reference sounds incorrect behaviour to me.
Consider a web site that does shopping cart processing.
The web site wants to retain your shopping cart
(stateful session bean) if it has to passivate the
web session. It does this by serializing a Handle to
the bean.
Automatic remove() would break this.
The spec does allow for a timeout based on client
inactivity, after which automatic removal is done
by the container.
Look at <cache-policy-conf> in standardjboss.xml
Regards,
Adrian -
7. Re: EJB's never being garbage collected
adrian.brock Aug 23, 2002 5:01 PM (in response to jasonb2)Of course if you want this behaviour,
write a client side interceptor that calls remove
in finalize().
finalize isn't guaranteed to be run anyway.
Regards,
Adrian -
8. Re: EJB's never being garbage collected
adrian.brock Aug 23, 2002 10:27 PM (in response to jasonb2)For future reference:
The client side interceptor will only work if it has
a handle to the session bean (the other parts of its
current client containter could already be garbaged
collected)
and the garbage collector thread can obtain security info
i.e. from a multi user client, like a web container,
forget it.
Regards,
Adrian -
9. Re: EJB's never being garbage collected
juha Aug 24, 2002 5:25 AM (in response to jasonb2)> Yes, it does garbage collect after being passivated, but I was under the impression that when it is
> passivated, it is written to the disk so that it can be activated later.
Correct.
> I have EJBs that will never be used again, so I
> wouldn't want them passivated - I would want them
> removed altogether.
There's a scavenger thread that will go through the disk space and remove passivated sessions if they were never activated again. You can configure both the passivation timeout and the scavenger period in your JBoss config.
Or explicitly remove the session by using the remove() call.
> Does this not happen when the remote object is
> garbage collected on the client?
No, it doesn't.
-- Juha -
10. Re: EJB's never being garbage collected
jasonb2 Aug 26, 2002 1:35 PM (in response to jasonb2)My thanks to everyone who helped. Just knowing that I have to explicitly call the remove is enough. It really isn't any problem to add that call.
Thanks,
Jason