Hi Hong,
These are the calls that use DC:
EjbDeployer: clean() & Deployment.APPLICATION_PREPARED event -
DeploymentProperties.PREVIOUS_TARGETS
EjbDeployer.load() - EJB_APP_MARKED_AS_STARTED_STATUS & CONTAINER_LIST_KEY
EjbApplication.loadContainers() "org.glassfish.ejb.startup.SingletonLCM"
& CONTAINER_LIST_KEY
-marina
Hong Zhang wrote:
> Hi, Marina
> I just replied to Mitesh for a similar question. :-)
> I believe in the these cases, the states are stored as transient
> metadata of the ApplicationInfo object instead of DeploymentContext
> object (please do double check your use cases). The ApplicationInfo
> object lives in memory until the undeployment so it's possible to
> transfer state using that.
> The DeploymentContext is intended to a transient object which only
> lives for certain operation and then disappear. We use different
> instances of DeploymentContext for deployment, undeployment etc. So we
> could not use it to transfer states in the first place.
> So Tim's changes should not affect these use cases as it only
> cleans up DeploymentContext.
>
> Thanks,
>
> - Hong
>
> On 6/6/2011 6:37 PM, Marina Vatkina wrote:
>> Tim,
>>
>> EJB container uses transientAppMetaData on load/unload and clean on
>> undeploy. From my previous discussions with Hong, undeploy can be
>> done on a disabled application, when none of the DOL data is
>> processed. Unless something has changed, several EJB features won't
>> be available with the change.
>>
>> Best,
>> -marina
>>
>> Tim Quinn wrote:
>>> If you are responsible for a GlassFish module container, please read
>>> on.
>>>
>>> The deployment framework makes available the DeploymentContext to
>>> all deployers that need to work with a given application. The
>>> intent has always been that the scope of a DeploymentContext is
>>> limited to deployment (or undeployment) processing only, not to the
>>> running application container.
>>>
>>> As part of our work to improve the memory footprint, beginning very
>>> soon (later today or within a day or so) the deployment framework
>>> will clear out the DeploymentContext's transient application
>>> metadata (accessible using the
>>> DeploymentContext.getTransientAppMetadata methods) at the end of
>>> deployment. No code should have been relying on this data past that
>>> point anyway.
>>>
>>> So far testing has not revealed any problems caused by clearing out
>>> that data, but you should double-check that your module will not be
>>> affected.
>>>
>>> We are adding this clean-up step because there are lingering
>>> references - after deployment - to the DeploymentContext which keeps
>>> it reachable after it should be eligible for GC. The DC's
>>> references to the transient app metadata consumed quite a bit of
>>> memory. Eventually we plan to make sure there are no such lingering
>>> references to the DC itself, in which case the DC and all referenced
>>> objects can be GCed. But that might be too risky for 3.1.1, so as a
>>> first step we are clearing out the transient app metadata.
>>>
>>> In the future you might need to change any container code that
>>> relies on a saved reference to the DC in order to improve further
>>> the memory footprint. We might not make this change right away, but
>>> please be aware that this could be very likely for some release past
>>> 3.1.1 if not for 3.1.1 itself, depending on the work we are
>>> continuing to do on improving the memory footprint.
>>>
>>> Please let me know if you have any questions.
>>>
>>> - Tim
>>>