Question

I’m pretty new to PL-SQL although I’ve got lots of db experience with other RDBMS’s. Here’s my current issue.

procedure CreateWorkUnit
is
update workunit 
set workunitstatus = 2 --workunit loaded 

where
    SYSDATE between START_DATE and END_DATE
and workunitstatus = 1 --workunit created;

--commit here?

call loader; --loads records based on status, will have a commit of its own

update workunit wu
set workunititemcount = (select count(*) from workunititems wui where wui.wuid = wu.wuid)
where workunitstatus = 2 

So the behaviour I’m seeing, with or without commit statements is that I have to execute twice. Once to flip the statuses, then the loader will run on the second execution. I’d like it all to run in one go.

I’d appreciate any words of oracle wisdom.

Thanks!

Answer 1

When to commit transactions in a batch procedure? It is a good question, although it only seems vaguely related to the problems with the code you post. But let’s answer it anyway.

We need to commit when the PL/SQL procedure has completed a unit of work. A unit of work is a business transaction. This would normally be at the end of the program, the last statement before the EXCEPTION section.

Sometimes not even then. The decision to commit or rollback properly lies with the top of the calling stack. If our PL/SQL is being called from a client (may a user clicking a button on a screen) then perhaps the client should issue the commit.

But it is not unreasonable for a batch process to manage its own commit (and rollback in the case of errors). But the main point is that the only the toppermost procedure should issue COMMIT. If a procedure calls other procedures those called programs should not issue commits or rollbacks. If they should handle any errors (log etc) and re-raise them to the calling program. Let it decode whether to rollback. Because all the called procedures run in the same session and hence the same transaction: a rollback in a called program will revert all the changes in the batch process. That’s not right. The same reasoning applies to commits.

You will sometimes read advice on using intermittent commits to break up long running processes into smaller units e.g. every 1000 inserts. This is bad advice for several reasons, not all of them related to transactions. The pertinent ones are:

1. Issuing a commit frees locks on resources. This is the cause of ORA-1555 Snapshot too old errors.
2. It also affects read consistency, which only applies at the statement and/or transaction level. This is the cause of ORA-1002 Fetch out of sequence errors.
3. It affects re-startability. If the program fails having processed 30% of the records, can we be confident it will only process the remaining 70% when we re-run the batch?
4. Once we commit records other sessions can see those changes: does it make sense for other users to see a partially changed view of the data?

So, the words of “Oracle wisdom” are: always align the database transaction with the business transaction, with a single commit per unit of work.

---

Somebody mentioned autonmous transactions as a way of issuing commits in sub-processes. This is usually a bad idea. Changes made in an autonomous transaction are visible to other sessions but not to our own. That very rarely makes sense. It also creates the same problems with re-startability which I discussed earlier.

The only acceptable use for automomous transactions is recording activity (error log, trace, audit records). We need that data to persist regardless of what happens in the wider transaction. Any other use of the pragma is almost certainly a workaround for a porr design, which actually just makes the problem worse.