This thread on the OTN forums…

http://forums.oracle.com/forums/thread.jspa?messageID=1455919&#1455919

…discusses a way to identify serializable transactions using the FLAG column in V$TRANSACTION. You may already be aware of this method and have chosen not to use it because it is not fully documented. Still, I thought it might interest you in case you were not aware of it.

Hope this helps,

Brian

With regards to your offline question of how this business rule would implement in RuleGen, here it is.

You need to tell RuleGen ‘when’ the rule needs to be checked. This particular rule needs to be checked when CLERKS are inserted or, in case of updates, the number of employees being promoted to CLERK exceeds the number being demoted (within a same department).

You specify this through queries on the ‘transition effect’ of the currently executed DML. RuleGen supplies views that hold the transition effect.

For inserts you register this query:
select distinct deptno
from v_insert_tx_effect
where new_job=’CLERK’
/

For updates you register this query:
select deptno
from (
select deptno,sum(case new_job
when ‘CLERK’ then 1
else 0) promoted
,sum(case old_job
when ‘CLERK’ then 1
else 0) demoted
from v_update_tx_effect
where updated_job=’true’
and (old_job=’CLERK’ or new_job=’CLERK’)
group by deptno)
where promoted-demoted>0
/

There is no need to register a query for deletes: they can never violate this rule.

Next you tell RuleGen, ‘how’ the rule should be checked, in case one of the queries above actually returns rows. This also is done through supplying RuleGen with a query. This query can use the selected values of the queries above (available through local variable with name p_.

Here is the ‘how’ for this rule.

select ‘At most three CLERKs allowed (found ‘||
to_char(num_clerks)||’) in department ‘||p_deptno||’.’
as msg
from (select count(*) as num_clerks
from emp
where job=’CLERK’ and deptno=p_deptno)
where num_clerks > 3
/

The semantics is that this query selects the actual error-message that should be reported back in case of a violation. If no row gets selected then the rule is considered OK.

And finally you need to tell RuleGen how code-execution for checking this rule is to be serialized, this is done via dbms-lock in a similar manner as your code above. In this case you register a call to a service procedure of RuleGen that acquires the necessary application lock for this rule: sp_rg_lock_rule(‘X’,'BREMP001′,p_deptno);

That’s it in a nutshell: for this rule you register the three queries mentioned plus the serialization code, then execute a service procedure to generate the triggers (or modify existing generated triggers) and you are done. The rule is maintained.

(there are a few more details to it, but the essence is the stuff above).

Regards,
Toon

PS: The issue with serializable isolation level is a known issue in the framework. I’m still trying to find a way to at least *detect* that the current transaction (or session) runs in serializable isolation mode. And if detected generate a generic error-message that rules cannot be maintained in this mode. But I haven’t found a way to do this, nor another way of getting the rule-validation robust in this mode (in an acceptable scalable manner, that is).

Thanks for your comment. You are making a good point, though in my experience it is rare for applications to use serializable isolation level and do data manipulation. But you are right: in those (perhaps not so frequently occurring) situations you have to be aware that the approach I present is not secure. So either you do not serialize or you do not do DML. If you want to do both, you may have to use the FOR UPDATE OF approach.

best regards,

Lucas

Note: For more observations on Isolation Levels, you may want to check out http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html.

For example consider the following sequence of events under two concurrent sessions, A and B.

1. Session A starts a new transaction *with serializable isolation level*.

2. Session B starts a new transaction and makes a “valid” change to EMP that fires the trigger and acquires the lock.

3. Session B commits, and Oracle releases the lock.

4. Session A makes a change to EMP that fires the trigger. Since A uses serializable isolation level, it can’t “see” the changes made by B. Since B’s lock has been released, it cannot prevent A from making a change that, when combined with the change made by B, violates the business rule.

There is a more concrete example of this (relating to preventing overlapping ranges) at http://asktom.oracle.com/pls/ask/f?p=4950:61:18110426428579554560::::P61_ID:474121407101#20229209009012.

Using release_on_commit => FALSE in DBMS_LOCK.REQUEST() will not solve the problem, because the lock could still be “prematurely” released — for example, if the session that started transaction B is closed before transaction A changes EMP.

So, SELECT…FOR UPDATE is too restrictive (since it prevents all concurrent changes, even if they don’t violate the business rule), and DBMS_LOCK is not completely robust.

You were absolutely right – now you are not anymore. I was still writing the article when I already posted part of it (afraid to lose content while editing) in the assumption that on a Sunday afternoon no one would read the article in the 20 minutes between the partial publication and the final post. However, I underestimated you – of course.

I have just completed the whole article. I think you will find the fundamental flaw described now – it is not robust! As well as a solution.

I would love to have your feedback on the complete article too by the way.

best reagrds,

Lucas

Again great post!

Good thoughts on integrity constraint implementation: you fail to mention though what it is that is ‘fundamentally flawed’. Unless you mean that checks are executed too many times. Your solution to that issue will not work when the rule typically involves three or more tables: rules do not have a single ‘case’ (as was the department key in your example) any more.

Also I would expect that you were going to mention that one has to think about locking ‘something’ in order for the triggers firing simultaneously to still enforce the rule correctly.

Toon