Executive summary

Peak loads often transform a healthy Oracle Integration (OIC Gen3 / Integration 3) flow into intermittent timeouts—especially when a downstream database slows down and the integration holds connections open too long. Using a real community scenario (PostgreSQL via Agent → Fusion receipt creation → PostgreSQL back update), this post explains three design options and when to use each: (1) in‑instance fork/join parallelism, (2) chunking with continuation, and (3) a parent–child pattern. The goal is to reduce long‑running instances, keep database transactions small, and apply controlled concurrency. [Ref 5]

The real‑world scenario (from the forum thread)

A common integration pattern is: SQL fetch (via DB Adapter) → Fusion creation (REST/SOAP/ERP Adaptor) → SQL back update (via DB Adapter). In the reported case, the integration often finishes in under 4 minutes, but during peak load it can take 15–20 minutes and then fails during the SQL back update with a JDBC socket timeout (java.net.SocketException: Connection timed out).

When this happens, simply ‘increasing the timeout’ is usually a band‑aid: it may postpone failures, but it does not address the underlying cause—slow downstream response, long transactions, contention/locks, or oversized batches. A more robust fix is to redesign the flow so each unit of work is bounded in time and size. [Ref 3]

Option 1 — Fork out / fork in parallelism inside a single integration

In OIC Gen3, you can model fork/join parallelism using the Parallel action, which splits the integration into branches that execute concurrently and then automatically synchronize before the main flow continues. This is ideal when you have a small number of independent tasks (for example, calling multiple endpoints and then comparing results). [Ref 1]

Pros

• Best for reducing wall‑clock time when branches are independent (e.g., parallel outbound calls). [Ref 1]
  
• Single instance visibility: branches appear in the activity stream and the flow resumes after all branches complete. [Ref 1]
  
• Good fit for ‘split‑then‑aggregate’ use cases where results must be merged before proceeding. [Ref 1]
  

Cons / risks

• Parallel action has a maximum of five branches, which limits scale‑out within one instance. [Ref 1]
  
• No branch‑specific fault handling; error handling is global, which can complicate partial‑failure strategies. [Ref 1]
  
• Global variable synchronization isn’t supported in parallel branches, making shared‑state patterns risky. [Ref 1]
  
• Nesting constraints apply (for example, parallel actions cannot be nested and are restricted within looping/chunking patterns). [Ref 1]
  

When to use

Use Option 1 when you have a small, fixed number of independent tasks and need a clean fork/join with a single end‑to‑end instance trace. In the PostgreSQL timeout scenario, parallelism may help reduce time spent on the Fusion receipt calls if the downstream supports it, but it rarely fixes a slow database writeback on its own. [Ref 1, Ref 5]

Option 2 — Chunking / batching with continuation (process N records per run)

Chunking breaks the workload into smaller batches (for example, 500–1,000 records). Each batch completes quickly, commits results, and then the next batch is processed until the backlog is cleared. This reduces transaction size and lowers the probability of long waits causing timeouts. It also aligns with Oracle’s guidance to avoid long‑running scheduled integrations that block resources and create backlogs. [Ref 3, Ref 5]

Pros

• Directly reduces DB back‑update transaction size (smaller updates, shorter locks, less time waiting for the DB). [Ref 5]
  
• Predictable runtime per batch; easier to keep executions within safe time windows. [Ref 3, Ref 5]
  
• Natural throttling control: tune batch size and pacing to match DB and Fusion capacity. [Ref 5]
  
• Improves scheduler health by avoiding very long schedule executions that can impact other scheduled runs. [Ref 3]
  

Cons / risks

• Requires strong idempotency and checkpointing to avoid duplicates when batches retry or restart. [Ref 5]
  
• Monitoring is distributed across multiple integration instances; you need correlation IDs or a tracking store to view job‑level progress. [Ref 5]
  
• ‘Integration calls itself’ recursion can become fragile without strict stop conditions; many teams prefer a controller/dispatcher instead. [Ref 3]
  

Implementation blueprint (recommended)

A proven approach is to maintain a status field in the source table (NEW → IN_PROGRESS → DONE/ERROR) and process the next batch using a stable ordering key. Update rows to IN_PROGRESS quickly, then process each item and write back DONE/ERROR with error details. The key is to keep each DB update small and frequent rather than one large end‑of‑run update. [Ref 5]

High‑level pseudo‑flow:

1) SELECT next 500–1000 rows WHERE status=’NEW’ ORDER BY id
2) UPDATE selected rows SET status=’IN_PROGRESS’, run_id=…
3) FOR EACH row:
– Create receipt in Fusion (REST/SOAP)
– UPDATE row SET status=’DONE’ (or ‘ERROR’ + reason)
4) Kind of – call the integration again to continue with rest if something remains

Option 3 — Parent–child orchestration (controller + worker integrations)

The parent–child pattern splits responsibilities: a parent (controller) integration selects work and dispatches it to child (worker) integrations that process bounded chunks. Oracle’s design best practices recommend decomposing heavy scheduled flows so the schedule runs quickly and invokes child integrations asynchronously, reducing scheduler contention and timeout risk. [Ref 3]

Pros

• Best scalability with controlled concurrency: run multiple workers in parallel while keeping each worker batch small. [Ref 3, Ref 5]
  
• Failure isolation: one worker failure doesn’t collapse the entire job; retries become targeted. [Ref 3, Ref 5]
  
• Scheduler friendly: parent finishes quickly after dispatch, reducing backlog risk for scheduled jobs. [Ref 3]
  
• Modularity and maintainability: smaller integrations are easier to test, deploy, and evolve. [Ref 3]
  

Cons / risks

• More artifacts to manage (multiple integrations, versions, deployments). [Ref 4]
  
• Invocation constraints and project/public configuration requirements apply when invoking child integrations. [Ref 4]
  
• If you need a ‘job complete’ signal, you’ll typically implement coordination via a table/queue and correlation IDs. [Ref 5]
  

When to use

Choose Option 3 when you need both reliability and throughput—especially for month‑end peaks. Combine it with chunking: the parent dispatches batch keys (or ID ranges) and each worker processes 500–1000 rows with small DB writebacks. This is often the most robust pattern for ‘DB slows down at peak’ scenarios. [Ref 3, Ref 5]

Decision guide (quick rules of thumb)

1. If you need fork/join over a small number of independent tasks (≤5): use Parallel action. [Ref 1]
   
2. If the failure happens during DB writeback or you see timeouts under load: start with chunking (Option 2). [Ref 5]
   
3. If you need chunking plus controlled scale‑out and better fault isolation: implement parent–child (Option 3). [Ref 3, Ref 4, Ref 5]
   
4. Use For‑Each ‘Process items in parallel’ carefully; ensure ordering isn’t required and avoid shared global state updates in the loop. [Ref 2]
   

References

• [Ref 1] Oracle Documentation — Process Tasks in Parallel with a Parallel Action (Oracle Integration 3): https://docs.oracle.com/en/cloud/paas/application-integration/integrations-user/process-tasks-parallel-parallel-action.html [turn1search7]
• [Ref 2] Oracle Documentation — Loop over Repeating Elements with a For-Each Action (includes ‘Process items in parallel’): https://docs.oracle.com/en/cloud/paas/application-integration/integrations-user/loop-repeating-elements-each-action.html [turn1search10]
• [Ref 3] Oracle Documentation — Design Best Practices (avoid long-running schedules; use async/child integrations): https://docs.oracle.com/en/cloud/paas/application-integration/integrations-user/common-integration-style-pitfalls-and-design-best-practices.html [turn1search1]
• [Ref 4] Oracle Documentation — Invoke Child Integrations Inside or Outside of Projects (capabilities & restrictions): https://docs.oracle.com/en/cloud/paas/application-integration/integrations-user/invoke-integrations-other-projects-or-projects.html [turn1search24]
• [Ref 5] Oracle Cloud Customer Connect thread extract (attached document): ‘timeout – OIC3 – PostgreSQL adapter — Cloud Customer Connect.docx’ [turn2search1]