У меня есть таблица со следующими полями:
entry_id BIGSERIAL PRIMARY KEY,
site_id BIGINT NOT NULL,
uuid VARCHAR(256) NOT NULL,
session_start TIMESTAMP NOT NULL,
session_end TIMESTAMP NOT NULL,
user_ip VARCHAR(40) NOT NULL,
user_agent VARCHAR(256) NOT NULL,
Теперь у меня много входящих запросов с кортежами данных типа (site_id, uuid, timestamp, user_ip, user_agent)
.
Мое правило состоит в том, что если в базе данных есть запись, возраст которой менее 3 часов (session_end), то входящий запрос обновляет session_end = timestamp
. Если нет, создайте новую запись (где session_start = session_end = timestamp
).
Входящие запросы обрабатываются несколькими процессами. Скажем, 3-4 входящих запроса попадают на мои серверы с одинаковыми данными (разные временные метки, но в миллисекундах) и обрабатываются 3 разными процессами - как мне избежать создания 3 разных записей (если все они проверяют одновременно, см. нет совпадений записей и каждая создает новую)? Это вопрос состояния гонки, и я не знаю, как его обеспечить.
Блокировка таблицы кажется излишней, поскольку это таблица с большим объемом записи, но какие у меня есть альтернативы помимо механизма блокировки стороннего производителя?
Пример:
Format:
(site_id, uuid, timestamp, user_ip, user_agent)
Incoming requests / data:
(1, 123, 2014-01-01T10:00:32, '123.123.123.123', 'Mozilla/Chrome')
(1, 123, 2014-01-01T10:00:33, '123.123.123.123', 'Mozilla/Chrome')
(1, 123, 2014-01-01T10:00:34, '123.123.123.123', 'Mozilla/Chrome')
Result tuple:
entry_id | site_id | uuid | session_start | session_end | user_ip | user_agent
--------------------------------------------------------------------------------------------
<auto> | 1 | 123 | 2014-01-01T10:00:32 | 2014-01-01T10:00:34 | ... | ...
UNIQUE
индекса и обработки ошибок вставки в приложениях? - person Jakub Kania   schedule 02.09.2014select version();
- person Clodoaldo Neto   schedule 02.09.2014