Do Concurrent Programs Auto-Commit in Oracle E-Business Suite R12?

This is a question that often comes up during interviews, code reviews, and production issue analysis:

Do Oracle EBS concurrent programs auto-commit?

Many developers assume the answer is simply “Yes”, but the real behavior is more nuanced. I recently revisited this topic, tested it practically, and want to share the exact findings here.

---

Common Assumptions

There are two popular beliefs among Oracle EBS developers:

1. Concurrent programs auto-commit by default

2. Commit or rollback should always be controlled explicitly by the developer

At first glance, both seem reasonable. Oracle generally encourages explicit transaction control, and database-level auto-commit would be a risky design choice. So what actually happens?

---

Key Finding (Tested Behavior)

Oracle EBS concurrent programs do NOT use a database-level or session-level auto-commit.

Instead, the Concurrent Manager decides whether to COMMIT or ROLLBACK based on the program’s RETCODE.

This behavior applies even if no explicit COMMIT or ROLLBACK exists in the PL/SQL code.

---

How Commit / Rollback Is Decided

1️⃣ When the program completes successfully

If a concurrent PL/SQL program ends with:

• RETCODE = 0 (Normal), or

• RETCODE = 1 (Warning)

👉 All database changes are COMMITTED automatically by the Concurrent Manager.

This effectively behaves like an auto-commit, but it is controlled externally.

---

2️⃣ When the program ends with an error

If the program ends with:

• RETCODE = 2 (Error), or

• An uncaught exception

👉 All database changes are ROLLED BACK.

---

3️⃣ Important detail about RETCODE

• Oracle internally performs TO_NUMBER(RETCODE)

• Any invalid number is treated as 0

• Any value greater than or equal to 2 is treated as Error

• If ERRBUF and RETCODE parameters are passed incorrectly, you may unknowingly cause a COMMIT

This makes correct parameter handling critical.

---

Why This Design Makes Sense

Although skipping explicit COMMIT / ROLLBACK may look like bad practice at first, this behavior provides flexibility:

• Allows testing in SQL*Plus without committing data

• Enables the program to be used as a subroutine by other packages

• Lets the calling program decide transaction control

This design aligns with how many Oracle standard APIs work.

---

Best Practices (Strongly Recommended)

Even though Oracle EBS supports this implicit behavior:

✔ Always write explicit COMMIT or ROLLBACK in:

• Data-fix programs

• Interfaces

• Programs updating business-critical tables

✔ If you intentionally avoid commits:

• Clearly document the behavior

• Ensure RETCODE is set correctly

• Consider using a commit control parameter, similar to Oracle standard APIs

---

Final Answer (Interview-Ready)

Yes, Oracle EBS concurrent programs auto-commit or rollback, but not due to a database auto-commit. The Concurrent Manager commits or rolls back transactions based on the RETCODE value returned by the program.

---

Conclusion

Understanding how the Concurrent Manager controls transaction behavior helps avoid:

• Unexpected commits

• Partial data issues

• Debugging nightmares in production

If you’re working in Oracle EBS R12, this knowledge is essential—not optional.

---