dev@glassfish.java.net

Re: Module owners: Immediate (3.1.1 & beyond) limitations in scope of DeploymentContext data

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Mon, 06 Jun 2011 15:37:41 -0700

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
>