How to check if row to be inserted will cause circular circular loop?

Question

Hi-
I'm using connect by clause to do some processing and to check that the data is not causing circular loops (with SQLCODE = -1436).
Customers can add data via API, and this data, after inserted, can cause the problem explained above (loop). Therefore I need to find a way to check that these new values don't collide with the existing data in the table.
One way that currently works is to insert the data, use my pl/sql function to check that there's no loops; if there's a loop, i catch the exception, delete the rows I just inserted, and throw back the error to the user.
I find it very ugly and unneficient, but I can't find the way to use CONNECT BY with data that is not present in the table. example:
table my_table contains
parent_id | child_id
111 | 777
777 | 333
and now customer wants to insert:
parent_id | child_id
777 | 111
Also, if customer wants to insert
333 | 111
if I insert the row and run my script, it will work OK, but only if I insert the row. Is there any way to validate this without inserting/removing the row ?
the script I'm using is similar to the one posted here:
problems using CONNECT BY
thanks

Answer 1

This approach may fail to detect loops introduced by concurrent transactions if one of the transaction uses a serializable isolation level.
For example, assume there are two sessions (A and B), the table and trigger have been created, and the table is empty. Consider the following scenario.
First, session A starts a transaction with serializable isolation level:
A> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Transaction set.Next, session B inserts a row and commits:
B> INSERT INTO my_table (parent_id, child_id) VALUES (111, 777);
1 row created.
B> COMMIT;
Commit complete.Now, session A successfully inserts a conflicting row and commits:
A> INSERT INTO my_table (parent_id, child_id) VALUES (777, 111);
1 row created.
A> COMMIT;
Commit complete.
A> SELECT * FROM MY_TABLE;
PARENT_ID  CHILD_ID
      111       777
      777       111Session A "sees" the table "as of" a point in time before session B inserted. Also, once session B commits, the lock it acquired is released.
An alternative approach that would prevent this could use SELECT...FOR UPDATE and a "table of locks" like this:
SQL> DROP TABLE MY_TABLE;
Table dropped.
SQL> CREATE TABLE MY_TABLE
  2  (
  3      PARENT_ID NUMBER,
  4      CHILD_ID NUMBER
  5  );
Table created.
SQL> CREATE TABLE LOCKS
  2  (
  3      LOCK_ID INTEGER PRIMARY KEY
  4  );
Table created.
SQL> INSERT INTO LOCKS(LOCK_ID) VALUES(123);
1 row created.
SQL> COMMIT;
Commit complete.
SQL> CREATE OR REPLACE TRIGGER MY_TABLE_AI
  2      AFTER INSERT ON my_table
  3  DECLARE
  4      v_count NUMBER;
  5      v_lock_id INTEGER;
  6  BEGIN
  7      SELECT
  8          LOCK_ID
  9      INTO
10          v_lock_id
11      FROM
12          LOCKS
13      WHERE
14          LOCKS.LOCK_ID = 123
15      FOR UPDATE;
16         
17      SELECT
18          COUNT (*)
19      INTO  
20          v_count
21      FROM  
22          MY_TABLE
23      CONNECT BY
24          PRIOR PARENT_ID = CHILD_ID;
25 
26  END MY_TABLE_AI;
27  /
Trigger created.Now the scenario plays out like this.
First, session A starts a transaction with serializable isolation level:
A> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Transaction set.Next, session B inserts a row and commits:
B> INSERT INTO my_table (parent_id, child_id) VALUES (111, 777);
1 row created.
B> COMMIT;
Commit complete.Now, when session A tries to insert a conflicting row:
A> INSERT INTO my_table (parent_id, child_id) VALUES (777, 111);
INSERT INTO my_table (parent_id, child_id) VALUES (777, 111)
ERROR at line 1:
ORA-08177: can't serialize access for this transaction
ORA-06512: at "TEST.MY_TABLE_AI", line 5
ORA-04088: error during execution of trigger 'TEST.MY_TABLE_AI'To show that this still handles other cases:
1. Conflicting inserts in the same transaction:
SQL> TRUNCATE TABLE MY_TABLE;
Table truncated.
SQL> INSERT INTO my_table (parent_id, child_id) VALUES (111, 777);
1 row created.
SQL> INSERT INTO my_table (parent_id, child_id) VALUES (777, 111);
INSERT INTO my_table (parent_id, child_id) VALUES (777, 111)
ERROR at line 1:
ORA-01436: CONNECT BY loop in user data
ORA-06512: at "TEST.MY_TABLE_AI", line 15
ORA-04088: error during execution of trigger 'TEST.MY_TABLE_AI'2. Read-committed inserts that conflict with previously committed transactions:
SQL> TRUNCATE TABLE MY_TABLE;
Table truncated.
SQL> INSERT INTO my_table (parent_id, child_id) VALUES (111, 777);
1 row created.
SQL> COMMIT;
Commit complete.
SQL> INSERT INTO my_table (parent_id, child_id) VALUES (777, 111);
INSERT INTO my_table (parent_id, child_id) VALUES (777, 111)
ERROR at line 1:
ORA-01436: CONNECT BY loop in user data
ORA-06512: at "TEST.MY_TABLE_AI", line 15
ORA-04088: error during execution of trigger 'TEST.MY_TABLE_AI'3. Conflicting inserts in concurrent, read-committed transactions:
a) First, empty out the table and start a read-committed transaction in one session (A):
A> TRUNCATE TABLE MY_TABLE;
Table truncated.
A> SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Transaction set.b) Now, start a read-committed transaction in another session (B) and insert a row:
B> SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Transaction set.
B> INSERT INTO my_table (parent_id, child_id) VALUES (111, 777);
1 row created.c) Now, try to insert a conflicting row in session A:
A> INSERT INTO my_table (parent_id, child_id) VALUES (777, 111);This is blocked until session B commits, and when it does:
B> COMMIT;
Commit complete.the insert in session A fails:
INSERT INTO my_table (parent_id, child_id) VALUES (777, 111)
ERROR at line 1:
ORA-01436: CONNECT BY loop in user data
ORA-06512: at "TEST.MY_TABLE_AI", line 15
ORA-04088: error during execution of trigger 'TEST.MY_TABLE_AI'If updates are permitted on the table, then they could cause loops also, but the trigger could be modified to test for this.