This documentation is for WSO2 Application Server version 5.1.0. View documentation for the latest release.

Unknown macro: {next_previous_link3}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Out of four popular variants (Lazy Initialization, Virtual Proxy, Value Holder, Ghost) of the lazy loading design pattern, "Value Holder" and "Ghost" variants are adopted and used in the lazy loading implementation in WSO2 Carbon Framework.

Use of Value Holder

A value holder is an object, usually (but not necessarily) with a method by the name "getValue", which the clients invoke to obtain a reference to the real object corresponding to a parameter passed in the method. In WSO2 Application Server, the ValueHolder variant is used at the event of loading a tenant. The method call is as follow:

TenantAxisUtils.getTenantConfigurationContext(String tenantDomain)

The "getTenantConfigurationContext" method is the equivalent of the "getValue" method in the ValueHolder variant. It takes a "tenantDomain" as a reference and returns the ConfigurationContext, if the tenant is already loaded. If the tenant domain doesn't have an Axis2 ConfigurationContext, the method will return a newly created one. Either way, when loading an entire AxisConfiguration, all artifacts belonging to that particular tenant are also loaded. A more efficient practice is to lazy load those artifacts by loading only when it is requested by the system or a tenant. It prevents processing overhead and unnecessary memory usage. This is where the Ghost variant of the lazy loading pattern is used.

Use of GhostDeployer and GhostDispatcher/GhostWebappDeployerValve

When the Application Server starts, you can see all the previously deployed services and Web Applications listed in its management console. However, these artifacts are only the Ghost instances, which maintain references to the actual Instances. GhostDeployer, which handles lazy loading of artifacts, holds a map of deployers for all artifact types.

When a new artifact is deployed, the GhostDeployer creates a Ghost Axis2 Service containing a special parameter (Ghost Parameter) to distinguish the service as a Ghost service, and then registers that service into the AxisConfig. When a user requests a particular service artifact, the GhostDispatcher, which is an Axis2 dispatching handler, checks the Ghost Parameter added to the service to determine if it is the actual artifact or the ghostified form. If it is the latter, the actual deployer is called to load the actual service and the rest of the metadata from the registry, service policies and other information regarding the artifact.

GhostWebappDeployerValve, on the other hand, is used with lazy loading for web applications. It is a Tomcat Valve, which intercepts the incoming http requests, and does the same work as GhostDispatcher in Axis2. It intercepts the incoming webapp request and checks for the Ghost parameter in the webapp and load the actual webapp, if it found to be in ghost form. This is new feature available from this release, and perhaps the first time, lazy loading for web application is implemented for Tomcat.

The WSO2 Application Server also maintains an unloader task, which periodically checks for inactive artifacts and replaces them with its ghostified form.

  • No labels