Zachowanie, które napotkałeś w przypadku POMIJANIA AKTUALIZACJI ZABLOKOWANEJ, zostało opisane w tej notatce na blogu. Rozumiem, że klauzula FOR UPDATE jest oceniana PO klauzuli WHERE. SKIP LOCKED jest jak dodatkowy filtr, który gwarantuje, że wśród wierszy, które zostałyby zwrócone, żaden nie jest zablokowany.
Twoje oświadczenie jest logicznie równoważne:znajdź pierwszy wiersz z card_numbers i zwróć go, jeśli nie jest zablokowany. Oczywiście nie tego chcesz.
Oto mały przypadek testowy, który odtwarza opisane przez Ciebie zachowanie:
SQL> CREATE TABLE t (ID PRIMARY KEY)
2 AS SELECT ROWNUM FROM dual CONNECT BY LEVEL <= 1000;
Table created
SESSION1> select id from t where rownum <= 1 for update skip locked;
ID
----------
1
SESSION2> select id from t where rownum <= 1 for update skip locked;
ID
----------
Żaden wiersz nie jest zwracany z drugiego wyboru. Aby obejść ten problem, możesz użyć kursora:
SQL> CREATE FUNCTION get_and_lock RETURN NUMBER IS
2 CURSOR c IS SELECT ID FROM t FOR UPDATE SKIP LOCKED;
3 l_id NUMBER;
4 BEGIN
5 OPEN c;
6 FETCH c INTO l_id;
7 CLOSE c;
8 RETURN l_id;
9 END;
10 /
Function created
SESSION1> variable x number;
SESSION1> exec :x := get_and_lock;
PL/SQL procedure successfully completed
x
---------
1
SESSION2> variable x number;
SESSION2> exec :x := get_and_lock;
PL/SQL procedure successfully completed
x
---------
2
Ponieważ jawnie pobrałem kursor, zostanie zwrócony tylko jeden wiersz (i tylko jeden wiersz zostanie zablokowany).
