everything that is transactional needs a commit.

all dbms_job.submit does is plop a row into a table. In order for that row to be "seen" by other sessions (specifically the job queue process), you need to commit it. Just like any other row in any other table.


It is transparent to end users.

To professional programmers, concerned about things like transactional integrity, it is equally transparent. You should know "in order to make changes permanent, we must commit when our transaction is over"

Imagine if it auto-committed. that would be horrendous.


I don't like the API's that auto-commit (like dbms_mview for example). *I* want to control the transaction from start to finish. Unfortunately, they considered dbms_mview to be more like DDL than an API

lets look at a couple of packages that don't commit and actually change data. packages like dbms_application_info that don't modify persistently stored data *don't count* of course, since there is nothing to "commit"


dbms_alert -- you need to commit to send the signal. imagine if it auto committed. Hmm, could not use it in a trigger to signal a session to re-read data since they would be signaled PRIOR to the row being actually visible!


dbms_aq -- imagine if the sending of a message automagically commited your transaction, what if your transaction consisted of "insert, send message, delete" in that order? it would be unusable.

dbms_job...

dbms_lock...