Proxy Authentication Support Oracle Database Adapter Features

9-34 Oracle Fusion Middleware Users Guide for Technology Adapters

9.3.8.1 Distributed Polling First Best Practice: SELECT FOR UPDATE SKIP LOCKED

The first best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL PM or Mediator nodes is to use the Adapter Configuration Wizard to set both the Distributed Polling check box in the Adapter Configuration Wizard and to set MaxTransactionSize. Increase concurrency by setting the adapter _db.JCA property NumberOfThreads. On an Oracle database, this will automatically use the syntax SELECT FOR UPDATE SKIP LOCKED. Concurrent threads will each try to select and lock the available rows, but the locks are only obtained on fetch. If an about to be fetched row is already locked, the next unlocked row will be locked and fetched instead. If many threads all execute the same polling query at the same time, they should all relatively quickly obtain a disjoint subset of unprocessed rows. On a non-Oracle database the SELECT FOR UPDATE will safely insure that the same row cannot be processed multiple times, however you may get less scalability. You should consider either using additionally a partition field or the second best practice which is essentially multi-threading on a single node with fan-out see Section 9.3.8.2, Distributed Polling Second Best Practice: Tuning on a Single Node First . When configuring this best practice, consider the following: ■ Section 9.3.8.1.1, Configuring PollingInterval, MaxTransactionSize, and ActivationInstances ■ Section 9.3.8.1.2, Partition Field ■ Section 9.3.8.1.3, activationInstances ■ Section 9.3.8.1.4, Indexing and Null Values ■ Section 9.3.8.1.5, Disabling Skip Locking ■ Section 9.3.8.1.6, MarkReservedValue ■ Section 9.3.8.1.7, SequencingPollingStrategy Last Read or Last Updated

9.3.8.1.1 Configuring PollingInterval, MaxTransactionSize, and ActivationInstances

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, so there is no danger of one instance fetching all the rows. 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. Hence, the maximum throughput with distributed polling enabled but uses SkipLocking disabled is: NumberOfThreads x MaxTransactionSizePollingInterval Note: A distributed approach is required to insure that multiple activation instances do not process the same rows. Oracle JCA Adapter for Database 9-35 For load balancing purposes, it is dangerous to set the MaxTransactionSize too low in a distributed environment with skip locking disabled where MaxTransactionSize becomes a speed limit. It is best to set the MaxTransactionSize close to the per CPU throughput of the entire business process. This way, load balancing occurs only when you need it. For load balancing purposes, it is dangerous to set the MaxTransactionSize too low in a distributed environment where it becomes a speed limit. It is best to set the MaxTransactionSize close to the per CPU throughput of the entire business process. This way, load balancing occurs only when you need it. If distributed polling is not set, then the adapter tries to process all unprocessed rows in a single polling interval.

9.3.8.1.2 Partition Field In a distributed scenario you will have polling instances on

multiple servers, however per server you will likely also have more than one thread configured. You can configure these activation instances to at least cooperate somewhat by processing separate rows, possibly improving scaling. Simply add the property PartitionField to your db.jca file: property name=PartitionField value=ID If you set activationInstances to 2, then activation instances 1 and 2 or 0 and 1 would respectively execute: SELECT ... WHERE ... AND MOD ID, 2 = 0 FOR UPDATE SKIP LOCKED and SELECT ... WHERE ... AND MOD ID, 2 = 1 FOR UPDATE SKIP LOCKED Activation instance 0 will still conflict with other activation instances with this ID on other servers, but at least it will not conflict with other activation instances with ID 1. Make sure that the partition field is numeric and that applying mod will evenly distribute the rows i.e. in this case make sure all the IDs are not either even or odd. On Oracle Database, you can set the partition field to be rowid by setting db.jca file property PartitionField as follows: property name=PartitionField value=rowid Note: Although you may want to increase MaxTransactionSize, if you increase it too high, you may start to see transaction timeouts. Table 9-2 lists safe values for MaxTransactionSize. Table 9–2 MaxTransactionSize and MaxRaiseSize Values MaxTransactionSize MaxRaiseSize Description 10 1 When using sequential routing. For 10 rows you will have 10 individual instances and 10 XML records passing through SOA. 100 When using parallel routing. = 100 MaxTransactionSize When using the adapter to stream rows through as fast as possible.