Oracle SOA 11g – Skip locking for DBAdapter connection factories in clustered environments

Skip Locking is the new property introduced in 11g for the DBAdapter Connection factories. “In a distributed scenario, each polling instance will try to balance the load by not greedily attempting to process all unprocessed rows by itself. What that means is that at a time, an instance will only fetch at most MaxTransactionSize rows”. When using skip locking, if a full MaxTransactionSize rows are fetched, the next MaxTransactionSize rows can be immediately fetched continuously. This is because concurrent threads do no block each other when using skip locking. The Skip Locking offers performance benefits. However, with skip locking disabled, all threads will try to lock the same rows, and only one will succeed. Consequently, once this thread has processed MaxTransactionSize rows, it will pause until the next polling interval, to allow other threads to also lock and process rows. If we want to limit the number of records processed(MaxTransactionSize) in a particular polling interval then the SkipLocking should be disabled, the maximum throughput for each node with distributed polling enabled but uses SkipLocking disabled is: NumberOfThreads x MaxTransactionSize/PollingInterval

DB Adapter Message Throttling in Oracle SOA 11g

DB throttling is the mechanism to control the number of database records processed by the SOA engine in a particular interval through DB Adapter.  Throttling also can be used to control the number of records send to the end systems. If the throttling is not defined, the end systems may flood with number of messages that will affect the functioning of the end systems. Throttling parameters should be configured based on the end systems capacity to process the incoming messages. Until Oracle SOA 11.1.1.6.0 the message throttling will not work as we expect, all the messages matching the where condition of the polling sql are processed in the same polling interval. As of Oracle Adapters release 11.1.1.6.0 we can set the inbound DBAdapter property RowsPerPollingInterval to control the throttling. It acts as a limit on the number of records which can be processed in one polling interval. The default value is unlimited. The Patch 12881289 should be applied to enable this for SOA 11.1.1.5.0 and earlier versions. The maximum rows processed per second are: Number of active nodes in SOA cluster x NumberOfThreads x RowsPerPollingInterval / PollingInterval MaxTransactionSize can be thought of as RowsPerDatabaseTransaction or DatabaseFetchSize that is how many records will be fetched to DB Adapter engine from the database for each transaction. It does not affect how many rows can be processed in one polling interval period. The one exception is the following configuration: -distributed polling checked, usesSkipLocking="false" In this one case RowsPerPollingInterval will default to MaxTransactionSize instead of unlimited in case of RowsPerPollingInterval property is not specified in the jca file. If RowsPerPollingInterval is set to lower than MaxTransactionSize or MaxRaiseSize, they will be effectively lowered to RowsPerPollingInterval that means the value RowsPerPollingInterval will considered for MaxTransactionSize and MaxRaiseSize. There is no UI support to add the RowsPerPollingInterval property. We have to add the property manually to the db.jca file for the inbound polling service. Add it to the same section as the properties MaxRaiseSize, MaxTransactionSize, and PollingInterval, in any order.