Just ran into exactly the same issue with AIX and 10.2.0.4

The answer i got from support

It’s not a bug…this is the expected behavior.
Stored procedures calls invoked by the scheduler are wrapped in an autonomous transaction…and in 10g,parallel DML is disabled inside autonomous transactions.

So I was given 3 choices…
1. Upgrade to 11g…Which does allow you to use PDML
2. Not use the scheduler …which for us defeats the whole purpose…
3. There is a one of patch for 10.2.0.3 and 10.2.0.4 which will enable the use parallel DML inside procedures called by the scheduler

This is a good point. Two things

- tou can prevent the implicit commit by using an autonomous transaction (google for more)

- there is a good reason for this behaviour. scheduler objects are full database objects like tables and stored procedures so they appear in all_objects and can be granted privileges on. So a create_job call is basically a DDL statement like a CREATE TABLE, which is why it auto-commits.

Cheers,
Ravi.

1) do some DML
2) submit a dbms_job which does some DDL
3) then an error happens, ROLLBACK occurs and the job doesn’t run which is what we want

Any ideas on how to achieve the above now that dbms_job is supposed to be superseded and I guess I’m trying to do a bit of future proofing?

I’d think this behavior is normal .. since the procedure is run in a different session and upon exit it does an implicit commit. That behavior is not limited to a sql*plus session or for a dbms_job job…
Most oracle utilities and tools issue an implicit commit upon session exit.

The doco states that too:
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_4010.htm

Oracle recommends that you explicitly end every transaction in your application programs with a COMMIT or ROLLBACK statement, including the last transaction, before disconnecting from Oracle Database. If you do not explicitly commit the transaction and the program terminates abnormally, then the last uncommitted transaction is automatically rolled back.

A normal exit from most Oracle utilities and tools causes the current transaction to be committed. A normal exit from an Oracle precompiler program does not commit the transaction and relies on Oracle Database to roll back the current transaction.

So even with dbms_scheduler, one should issue an explicit commit so that the
final intention is clear.

However, an odd behavior with dbms_scheduler.submit_job is that it submits
the job and does an implicit commit. Folks used to use dbm_job.submit to
submit jobs which came in effect only if an explicit commit was issued. Coding
same thing using dbms_scheduler might give them a rude shock since the
call itself is doing an implicit commit…

Anurag

I guess dbms_job might work the same way, but I never left the “explicit commit” out of the code before and was not aware of the behaviour.

I checked the documentation and could not find it…at least it was not in any place obvious….kinda like the implicity commit in SQL*Plus when you exit. But that one I knew about already.

Are you referring to an implicit commit done by the statement:

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => ‘BABETTE_JOB’,
job_type => ‘STORED_PROCEDURE’,
job_action => ‘avail.update_babette’,
start_date => sysdate,
repeat_interval => ‘FREQ=MINUTELY’,
enabled => TRUE);
END;
/

or are referring to the commit done in the job which got execute.
The jobs created in dbms_job behave no differently since they do
an implicit commit also.

However, the calls to dbms_scheduler do an implicit commit
which calls to dbms_job did not.
So after dbms_scheduler.create_job, one does not need to
do a commit to have the job submitted.
However, one needed to do a commit after dbms_job.submit
for the job to be submitted.

Regards,

Anurag