Tuning Oracle SOA 11g can be achieved in a few steps to tackle the most common performance issues at the infrastructure level. On the other hand, most performance issues are in the application (composite application) itself. If you design a bad application, the application will not perform well.

Tuning the Oracle SOA infrastructure involves the following:

  • JVM Memory
  • JVM Garbage Collection
  • Datasources
  • Threads
  • EJB
  • Database

Tuning JVM Memory

The JVM Memory settings are extremely important for Oracle SOA 11g. It is recommended to set the minimum head size to 2048MB and the maximum heap size to 4096MB or more depending on the availability of your physical resources on which the SOA platform is installed.

Also, setting the PermSize and the MaxPermSize is extremely important. Make sure that the PermSize is set to at least 512MB and the MaxPerSize is at least 1024.


-Xms2048M -Xmx4096M -XX:PermSize=512M -XX:MaxPermSize=1024M

Setting JVM Garbage Collection

If your SOA Suite is running on a single CPU machine, then setting the garbage collection to parallel will not improve the performance. However; if your SOA suite is installed on a virtual machine running on a VMWare ESX host; then setting this option will improve your system’s performance significantly.


-XX:-UseParallelGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing

Tuning SOA Suite 11g DataSources

Configuring and optimizing your back-end connections for SOA suite is essential for the overall system performance. It is recommended to measure your connections to the database by running a series of load tests in order to capture the appropriate measurement and properly define these parameters.

It is recommended to tune the below Oracle SOA 11g DataSources:

  • BAMDataSource
  • EDNDataSource
  • EDNLocalTxDataSource
  • mds-soa
  • SOADataSource
  • SOALocalTxDataSource

Set the following parameters for each DataSource using the Weblogic Administrative Console as follow:

  • Initial Capacity=0
  • Maximum Capacity=100
  • Capacity Increment=1
  • Statement Cache Type=LRU
  • Statement Cache Size=0
  • Test Connections On Reserve=TRUE
  • Test Frequency=180
  • Seconds to Trust an Idle Pool Connection=30
  • Shrink Frequency=300
  • Connection Creation Retry Frequency=30
  • Inactive Connection Timeout=30
  • Maximum Waiting for Connection=2147483647
  • Connection Reserve Timeout=30
  • Statement Timeout=-1
  • net.CONNECT_TIMEOUT=100000
  • Set XA Transaction Timeout=TRUE
  • XA Transaction Timeout=0
  • XA Retry Duration=300
  • XA Retry Interval=60


It is not recommend modifying to the default threading model for the Oracle SOA 11g Suite. Weblogic uses an automated mechanism for tuning its execution of threads. WebLogic Server prioritizes the requests and allocates threads based on an execution model that takes into consideration the managed servers parameters and actual run-time statistics.

Tuning threads within Oracle SOA 11g Suite will require tuning the threads of the BPEL engine itself. This can be achieved through the Weblogic Enterprise Manager. The threads will use a database connection from the pool.

Set the following parameters for the BPEL engine through EM:

  • dspInvokeThread=10
  • dspEngineThreads=15
  • dspSystemThreads=2
  • synMaxWaitTime=150


The soa-infra application includes all the EJB objects required for Oracle SOA 11g Suite. Each of these EJB objects has a pre-defined time out setting. By default, this setting is 300 seconds. Time-out errors could occur in the case of long running processes that could slow down the overall SOA system. Therefore you should not just count on tuning the soa-infra application but also it is highly recommended to design and implement efficient and optimal composites.

To change the time-out of the EJB’s, you will need to go through steps described below:

  • Log in to the weblogic administrative console.
  • Undeploy the soa-infra application and activate the changes.
  • Redeploy soa-infra application with configuration file (Plan.xml) from $ORACLE_HOME/soa/applications/soa-infra-wls.ear with all the new EJB time-out settings. Make sure to copy the application to all servers.
  • Activate changes
  • Start soa-infra application to server all requests.

Below is a sample of the Plan.xml configuration file:

Please note the following timeout settings in the configuration file:

  • TransactionDescriptor_transTimeoutSeconds_BPELEngineBean=1800
  • TransactionDescriptor_transTimeoutSeconds_BPELDeliveryBean=1800
  • TransactionDescriptor_transTimeoutSeconds_BPELActivityManagerBean=1800
  • TransactionDescriptor_transTimeoutSeconds_BPELServerManagerBean=1800
  • TransactionDescriptor_transTimeoutSeconds_BPELProcessManagerBean=1800
  • TransactionDescriptor_transTimeoutSeconds_BPELInstanceManagerBean=1800
  • TransactionDescriptor_transTimeoutSeconds_BPELFinderBean=1800
  • TransactionDescriptor_transTimeoutSeconds_BPELDispatcherBean=1800
  • TransactionDescriptor_transTimeoutSeconds_BPELSensorValuesBean=1800

In addition, verify that the global transaction time out on all the managed servers is larger than the time out of the EJB. Make sure to set the global transaction time-out, JTA, to 3600 through the Weblogic Administrative Console.


Ensure first that you have followed the appropriate database configuration required for Oracle SOA 11g Suite explained in the Oracle SOA 11g Administrative Guide (Download from oracle.com). Most importantly, make sure that you can create enough processes and sessions to the database. The database must be tuned so that it has enough memory for caching, PGA, and SGA.

In addition, Oracle provides you with purging scripts. Make sure to use them in an appropriate manner and verify if you have added an index to the SOA dehydration tables.

Heavy Deploy/Undeploy or Instance Invocations Trigger Memory Leak and java.lang.OutOfMemory in SOA


Memory leaks may occur in Oracle SOA Suite where a large volume of composite deployments and undeployments may be taking place and/or composite instances are being invoked a large number of times between container restarts.

When using java memory tools like Visual Java and JRockit Mission Control to examine memory consumption by the Java heap, you notice that the WebLogic Managed Server running the BPEL process manager is seeing higher than expected levels of memory utilization. The memory utilization shows sustained and continued upward growth and memory used does not fall after periods of inactivity (where it can be confirmed that no deployments/undeployments or instance invocations have taken place) or after a Full GC is invoked.

Intermittently you may also be seeing:

  • lang.OutOfMemory errors, which cause the managed server to fail and need to be restarted.
  • Deployments of composites (both new deployments and re-deployments) fail with a transaction.internal.TimedOutException


Memory leaks in Oracle SOA 11g are caused by the XML processing libraries of the initial FMW release.

Since the deployment of a composite is one of the triggers for memory being leaked, as more and more deployments are initiated more and more memory is leaked. Eventually, the JVM where SOA is running will not have sufficient free memory within its heap to sustain activities that require more memory, such as deployments. When this occurs, the Garbage Collector will run continuously trying to find unused memory to free, thereby introducing a source of performance degradation that causes the system to run slowly. When this occurs, activities such as deployments will no longer be able to complete at all, therefore they will not have completed in the time expected by the transaction timeout (even if this were increased) and a weblogic.transaction.internal.TimedOutException will be seen in the log file.


Download and apply the following three patches, available via the Oracle Support Portal:

  • Patch 9811515

> PATCH#9811515
> =====================================================================
> Product: Oracle Fusion Middleware Family
> Release: iAS
> Platform or Language: Generic
> Size 4.1M (4346751 bytes)

  • Patch 9732292

> PATCH#9732292
> ===================================================================
> Description: MERGE REQUEST ON TOP OF FOR BUGS 6266258 9409052
>              9440430 9564546
> Product: Oracle Fusion Middleware Family
> Release: iAS
> Platform or Language: Generic
> Size 1.3M (1358348 bytes)

  • Patch 11779534

> PATCH#11779534
> ===================================================================
> Description: MERGE REQUEST ON TOP OF FOR BUGS 9822892 9568974 11686953
> Product: Oracle SOA Manager
> Release: iAS
> Platform or Language: Generic
> Size 11.6M (12165728 bytes)

Oracle SOA 11g Suite Performance Tuning