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
>>