stateless, mdb, entities are pooled.. what type of EJB do you use?
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.
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?
It should garbage collect after the stateful bean has been passivated. Is that not the case?
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?
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
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
Of course if you want this behaviour,
write a client side interceptor that calls remove
finalize isn't guaranteed to be run anyway.
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
and the garbage collector thread can obtain security info
i.e. from a multi user client, like a web container,
> 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.
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.
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.