Wednesday, October 1, 2008

how to optimally configure the number of database connections in BPEL

In any project one of the most important step towards performance tuning is to configure the number of connections to the DB .If the number of requests are more than the number of connections to database, the requests will have to wait till the connections are free. It is not easy to come up with the number of connections required to connect to the DB. It depends on lot of factors like the load on the server, how many threads are simultaneously required to process a request. You can only come up with an optimal number depending on the different dependent factors. Today I will discuss the dependent factors that you need to consider when you work on a BPEL Server.

First we will look at what type of requests are processed inside the server

Usually it can be categorized as one-way invocation and two-way invocation (request-response model)

For both types of invocation, under normal scenarios the threads processing the requests will use one connection each.

Below I am listing the different factors which will influence the max-connection attribute of connection-pool.

  • dspMaxThreads BPEL Property

This property sets the maximum number of active dispatcher threads that process messages during peak load times. It depends on the load of the server-expected maximum parallel requests. Usually dspMaxThreads <= WorkerBean threads.

  • nonBlockingInvoke BPEL Property

Even though you use Flow or FlowN in your bpel process Oracle BPEL Process Manager executes it in a single thread, executing the branches sequentially instead of in parallel. When nonBlockingInvoke property is set to true, the process manager creates a new thread to perform each branch’s invoke activity in parallel.

  • WorkerBean

Oracle BPEL Server uses an MDB called WorkerBean to perform processing. In the case of one-way invocation(durable process) the request to the server is placed in a queue. Inside Oracle BPEL Server, a message-driven bean (MDB), WorkerBean, monitors the queue for invocation requests and then it is dequeued and assigned a new thread for servicing the request

  • InvokerBean

The invoker bean is used only for nonblocking invoke activities. When nonBlockingInvoke property is set to true, BPEL Server spawns a new thread to execute the invocation. InvokerBean is the one which creates new threads to service the request.

The number of connections required is evaluated on the basis of the above factors.

  • For a simple scenario

Maximum DB Connections >= (WorkerBean listener threads) + (Maximum concurrent request-response invocations)

  • If you are having only one domain

dspMaxThreads = (WorkerBean listener threads)

Maximum DB Connections >= (dspMaxThreads) + (Maximum concurrent request-response invocations)

  • If you are having multiple domains

Σdomains dspMaxThreads = (WorkerBean listener threads)

Maximum DB Connections >= (Σdomains dspMaxThreads) + (Maximum concurrent request-response invocations)

  • If nonBlockingInvoke is set to true

Maximum DB Connections >= (InvokerBean listener threads) + (WorkerBean listener

threads)+ (maximum concurrent request-response invocations)

You need to know the place where you can configure the data-source connection. The file can be found in ORACLE_HOME/ j2ee/home/config /data-sources.xml.

The following shows the place where you need to configure the number of connections

<connection-pool name=” MY_CONNECTION_POOL”








After you change the value you need to restart the server for the setting to take effect.


Anonymous said...

Very good Explanation. Please continue sharing your good work.


Shishir said...


Nice post there.

However, you haven't qualified which db you are talking about in the article - Is it the dehydration database or an external database which is being polled using database adapter - though am assuming it's the former one.


Georgie said...

yaa.. its mainly about the dehydration store. It can be extended to other databases to which the processes interact.