Is it correct to assume, that any objects referenced *only* by EJB's inside the container, could be garbage collected ?
(at least when every EJB is has been removed from the container..)
The conclusion would be, that any class library or any framework used only from inside the EJB container (i.e. by EJB's) *could* become subject to garbage collection and could be forced to re-initialize itself several times.
How then, can frameworks like 'Toplink' or 'JRules' work ?
Do such frameworks (for use inside EJB's) use special (proprietary) API's ?
I just thought of this:
Let's say some runtime-library for EJB's must initialize from some large XML document (let's say a persistence mapping..). To be *sure* this initialization has to be done only once (as long as the server is running) this could be done:
A singleton-class get's instantiated which reads this XML and initializes itself.
2) This singleton also instantiates *another singleton* (by calling it's getInstane() or just accessing it's class),
references it, and gives this other singleton a reference to itself.
So you end up with two singletons, *referencing each other* and hence can not be garbage collected !
Is this done in practice or am I overworked ?
JVM handles circular references so your singletons will be garbage collected when there's no object referencing any one of them, the JVM looks for accessibility, not reference counts.
So JVM handles circular references, thanks for reminding me of that.
But how can frameworks for EJB containers (Toplink, JRules, Carnot-workflow, ...) initialize themselfes then ?
Most if not all frameworks rely on some startup-initialization (to read some XML-config file for example).
If an EJB container has not a single EJB instantiated (ok, not very likely but still possible, right?), any initialization-class of that framework *could* possibly be garbage collected!
The next use of any framework-API by a (newly instantiated) EJB would force the framework to re-initialize itself (again reading XML-config files and so on...).
Isn't that a big performance-/state-keeping-problem for such frameworks ?
One way for such software is to integrate with the container. For example, last time I checked, TopLink could be integrated into WebSphere, WebLogic and HPAS EJB containers (meaning CMP support). TopLink can also be used (without container integratation) with any app server if you choose the BMP approach.
A software that can attach itself to the container may have a life-cycle of its own, independent of the EJBs it is associated to, so, no problem there.
Even if the container is not aware of the framework, garbage collection is not much of an issue. During startup, for each type of EJB, the container creates an EJB pool with some (upto the maximum number specified by the deployer) EJB instances in it. A create() on an EJBHome acquires an EJB instance from an EJB pool and a remove() releases the instance back to the pool. So, it's a very rare occurence when a container has no EJBs.
You could reset EJB pools via admin tools and maybe you would thus get the framework classes garbage collected. Whatever, I think it's no sweat.
1.2 and onwards JVMs don't GC classes unless *every* class loaded by a given classloader is unreferenced.
As I understand the class-gc issue, it does not change any behaviour in gc'ing *instances* in the heap.
A singleton is a class as well as it has an instance.
If the instance (of the singleton class) is gc'ed, it also has to re-initialize, possibly performing costly operations..
If any framework initialization has to be done in an EJB's setSessionContext() method, I would find that a bit awkward.
I can understand that frameworks must integrate with *the container*, but, because of the gc-issue, I can not see, how any one-time-only initialization can be done in any non-container-integrated framework...
You are correct -- the class GC changes don't affect GC of instances, but as long as a class has a static reference to the singleton instance the singleton instance won't be garbage collected.
Are there any singleton implementations where this isn't the case?