A new feature in SOA Suite 12c is composite lazy loading. This feature allows the components, WSDLs, and XSDs for a composite to be loaded as needed instead of at startup. This can help reduce start up time of the SOA servers from possibly as high as 30 minutes for domains with a large number of composites deployed, down to just a few minutes. We have worked with several customers who run SOA Suite 11g with hundreds of deployed composites. Many of the composites may be retired or previous versions simply for maintaining compatibility. Once utilizing SOA 12c, those customers will no longer have slow server start up times and can accomplish restarts much more quickly with less downtime for each node.
Enabling and Disabling Lazy Loading at the SOA-INFRA Level
Composite lazy loading and lazy deployment are both enabled at the soa-infra level by default in 12c.
You can find these settings by opening EM and right clicking on your domain and selecting System MBean Browser
Then, navigate to oracle.as.soainfra.config -> Server: soa_server1 -> SoaInfraConfig -> soa-infra
You will see two MBean attributes listed that control the lazy loading of composites:
- CompositeLazyDeployment - This is disabled by default and controls whether composites are lazy loaded when they are deployed
- CompositeLazyLoading - This is enabled by default and controls where composites are lazy loaded on server startup
You can enable or disable either of these options from this screen and click Apply when complete.
Overriding at the Composite Level
You also have the ability to override the soa-infra lazy loading settings at the composite level as well.
If you open your composite.xml, you can add an attribute called lazyLoading and set it to either true or false as shown below.
Lazy Loading in Action
If you are using the default settings, which enables composite lazy loading, you can see the components loading when you make your first request to the composite.
In the logs below you can see in the final log message that the composite was lazily loaded by the execute thread handling the incoming request.
In the lines before that you can see the individual BPMN components being loaded into the engine as well.
During this first execution you can see below that the request for a very simple composite took 3573ms
A 2nd request to the same service though only took 129ms after the composite had been fully loaded
By setting the lazyLoading attribute in our composite to false, we can now see that on server startup the composite and all of its components are loaded at once.
Now, our first request to the composite only took 911ms. This is still slightly higher than the 129ms we saw in the 2nd request above, but still much faster than the first request when using lazy loading.
By using lazy loading by default in SOA 12c you should see much quicker server start up times, especially if you have a large number of composites deployed, but there may still be cases where you would rather load specific composites at start up. In cases where a consistent, low latency response is more important that startup time you can still disable lazy loading at the composite level or for your entire domain.
Join the Conversation
Is this feature work for only newly deployed composites?
If we did an inplace upgrade from 11g to 12c, what would be the setting of lazyLoading?
How could we change if we needed?
I have not tested this in an upgrade scenario, but since your composites won't have any flags in them to override the soa-infra level setting I would check the system mbean shown in the post. It most likely will default to the standard 12c setting which enables lazy loading.
In BPMS11 we have a problem in starting server, since server ignores the SOA dependency between process and couldn't start some process.For solving this issue we use OSR in bpms11.
Is the lazy loading solve this problem ? or we must using OSR in BPMS12 as like as 11 ?
Thanks in advance