Последовательные потоки приложений и незафиксированные данные в Oracle

Question

Наше приложение считывает запись из таблицы «Событие» Oracle. Когда существует запись событий, мы обновляем поле «count» этой записи. Если запись не существует, мы ее вставляем. Поэтому мы хотим только 1 запись для определенного события в таблице.

Проблема с этим, вероятно, вполне предсказуема: один поток приложений будет читать таблицу, увидеть, что события там нет, вставить новое событие и зафиксировать. Но прежде чем он совершит второй поток, он также прочитает таблицу и увидит, что события там нет. И тогда оба потока вставляют событие, и в итоге мы получим 2 записи для одного и того же события.

Я предполагаю, что синхронизация доступа к этому конкретному методу в нашем приложении предотвратит эту проблему, но что является лучшим вариантом в Oracle, чтобы предотвратить это? Будет ли MERGE, например, всегда предотвращать эту проблему?

Answer 1

Сериализация доступа к процедуре, которая реализует эту функциональность, была бы тривиальной для реализации, используя DBMS_LOCK для определения и использования исключительной блокировки.

Сериализация по методам на базе SQL практически невозможна из-за модели согласованности чтения.

Answer 2

CREATE TABLE EVENTS (ID NUMBER PRIMARY KEY, COUNTER NUMBER NOT NULL); 

MERGE INTO EVENTS 
USING (SELECT ID, COUNTER FROM DUAL LEFT JOIN EVENTS ON EVENTS.ID = :EVENT_ID) SRC 
ON (EVENTS.ID = SRC.ID) 
WHEN MATCHED THEN UPDATE SET COUNTER = SRC.COUNTER + 1 
WHEN NOT MATCHED THEN INSERT (ID, COUNTER) VALUES (:EVENT_ID, 1); 

Простой SQL обеспечения одной записи для каждого идентификатора и последовательно увеличивая счетчик независимо от того, какое приложение запускает его или количество одновременных потоков. Вам не нужно ничего кодировать, и это тоже очень легкий вес.

Он также не производит никаких исключений, связанных с согласованностью данных, поэтому вам не нужна специальная обработка.

UPDATE: он фактически создает уникальное исключение нарушения, если оба потока вставляются. Я думал, что второе слияние переключится на обновление, но это не так.

ОБНОВЛЕНИЕ: Протестировано только одно и то же дело на SQL Server, а при параллельном выполнении и записи нет одной вставки MERGE и вторых обновлений.