Comments on: The Hunt for the Oracle Database On Commit trigger Friends of Oracle and Java Fri, 19 Dec 2014 15:08:31 +0000 hourly 1 By: Carmo Tue, 17 Jan 2012 12:09:58 +0000 It would be a good trigger on commit for the propagation of messages via the message queue Advanced Queue without impact on the current transaction.

I am wanting to use:



SAVE_LOG (‘…’)

By: Toon Koppelaars Sat, 12 Aug 2006 22:35:21 +0000 Lucas,

– Reanalyzing is *only* done when the current DML-statement “can potentially correct the violation”.
In practice this is frequently the next DML-statement. The violation is then cleaned out and no more reanalyzing takes place during the rest of the TX.

– Let’s do the ‘great Java debate’ first. Did you receive the any info yet?

– Finalizing chapter 6 as we speak. The book has 10 chapters in total.
‘Hard work’ would be the correct term yes.
Would be a lot easier if my coauthor would still be around to help finish it…


By: Lucas Jellema Sat, 12 Aug 2006 08:58:15 +0000 Toon,

Sounds very logical. Now if we could only access that memory location…

Is re-analyzing currently violated constraints for every statement a bit expensive performance wise for large transactions? When are we going to sit down and discuss RuleGen? I am getting intrigued!

How is your book coming along? Hard work I suppose?



By: Toon Koppelaars Fri, 11 Aug 2006 23:55:09 +0000 Lucas,

My 2 cents on the need for a commit trigger.

I think all constraint checking should be immediate.
Given the weakness of SQL DML though this is unfortunately
not possible.
Weakness 1: only one table can be changed by a statement.
Weakness 2: a table can only be changed in one way by a statement.
These weaknesses of SQL DML force us into dealing with ‘deferred
constraints’ and thus a solution for this such as a commit-trigger.

That given, what I think is the optimal way to deal with
this in SQL systems is as follows (and I think this is how Oracle
does it with deferable declarative constraints, however still need
to confirm this by running traces).

Every constraint is checked at statement level.
If it succeeds then all is OK.
If it fails to succeed (*and* it’s allowed so, i.e. defferable)
then this fact is ‘remembered'; it is stored somewhere (in memory)
that constraint so and so is violated for case so and so.
During every subsequent DML in the same transaction all stored violations
are re-checked (at the end of the DML execution). If success then the
violation stored in memory is cleaned up.

This enables the system to know at all times which deferrable constraints are currently being violated.

And that in turn means that at commit-time, no constraints need to be
checked anymore: the system only needs to do a memory lookup to see if current violations still exist. If so then give an error message.

By the way, this is the way the RuleGen engine does it.


PS It is very unfortunate that the SQL ISO commitee
‘invented’ that a failing commit should rollback the whole transaction.
It would have been much more practical to just have the commit fail
and have all dml-statements still posted.

By: Lucas Jellema Tue, 08 Aug 2006 07:21:15 +0000 John: Using a Table API does not seem to address the issue: the API gets called on a per table basis and I am looking for cross table, transaction level validation. Unless the Table API would always commit once the call is complete and I can insert my hook to transaction level validation prior to that commit, I do not see how the Table API would help. I am looking for a way to fire my custom code when the transaction is complete as far as the user or application is concerned.

Zlatko: I know of the set constraint immediate. The question is: who will do that? Does it need to be built into the application explicitly (currently yes).

Gary: I do not believe implicit commits from DDL are such an issue: most applications do not routinely perform DDL. And of course a certain amount of locking is a necessity when performing the business rule validation. Typically, with a rule like records in DEPT may not have more than three child records with JOB=CLERK in the EMP table, I want my session to have an exclusive lock on the combination of the specific DEPARTMENT and this particular Business Rule – and nothing else! So perhaps create a table with columns Logical_record_identifier and Business_Rule_Identifier and a unique constraint on the pair. Or use dbms_lock for user defined locks.

What I specifically do not want to do is exclude other sessions from doing any kind of business rule validation at all until my transaction commits. And I am afraid the MV solution may end inhibiting concurrency much more than it needs to.

By: Gary Tue, 08 Aug 2006 02:12:56 +0000 Personally, I think the ‘before commit’ trigger is the wrong solution to the problem.
There’d be a whole mess about the implicit commits from DDL.

But really the problems you identify with the materialized view solution are inherent to the issue, not that solution. Pretty much any complex business rule that you need to apply would need to implement the locking to ensure that it isn’t being violated as a result of different activity by different users.

By: Zlatko Sirotic Mon, 07 Aug 2006 17:28:37 +0000 “Deferred Constraints
…Note that when validation of deferred constraints runs into a violation, the entire transaction gets rolled back…”

But, you can verify the success of deferrable constraints prior to committing them by issuing a statement

See (for example):
Deferred Database Constraints and Forms
Solving “COMMIT business rules” on the Database Server (04/02/2002)

Best regards,
Zlatko Sirotic

By: John Flack Mon, 07 Aug 2006 14:59:02 +0000 This is probably a good argument for always using Table APIs (TAPIs) to do DML – never doing DML directly. That way, the API’s commit routine can include your ON COMMIT logic. Unfortunately, only Oracle Designer’s Web PL/SQL generator always creates applications that use a TAPI. Designer’s Forms generator CAN be told to use a TAPI too, but most people don’t. You would have to hand code Entity objects to use a TAPI with ADF Business Objects. Still, it wouldn’t be outside the realm of possibility to write a JDeveloper extension to generate Business Objects that use a TAPI.

By: Carl R. Mon, 07 Aug 2006 11:07:37 +0000 Hi,
we were on a search for an On Commit Trigger too for starting cleanup jobs before transactions is committed. The application uses an or-mapper. The or-Mapper changes data and link relations to objects too via a set of update statements. But only at he end of the transaction a database siede garbage collecter – implemented via PL/SQL – can clean up objects which are not referenced any more. For this cleanup an On-Commit Trigger would be the best.
Due to the missing feature we implemented a soft – commit procedure which calls the database side garbage collector before real commit;

I also would like to have an ON-ROLLBACK trigger ;-)
to cleanup non transactional PL/SQL Package environement.