Будет ли эта мьютексная реализация иметь смысл в PostgreSQL? - PullRequest
Новая
       37

Будет ли эта мьютексная реализация иметь смысл в PostgreSQL?

0 голосов
/ 20 марта 2019

Мне нужно реализовать синхронизацию между сеансами базы данных в PostgreSQL.

В SQL Server я бы реализовал это, создав собственную таблицу блокировки. 

Create table MyLock(LockName VARCHAR(100) NOT NULL UNIQUE, LockOwner INT NULL)

Я не использую явную транзакцию, чтобы избежать реальной блокировки, я бы заполучил свою «одиночную» блокировку, указав идентификатор сессии в качестве «владельца». 

UPDATE MyLock
  SET LockOwner = *MySessionId*
  WHERE LockName = 'Singleton' 
  AND LockOwner IS NULL;

Не используя явные транзакции, я не задерживаю другие процессы. Вы можете думать об этом как о "мягком замке" ...

Если мое обновление выполнено успешно, то я знаю, что у меня «есть» блокировка, и я могу обработать некоторый фрагмент кода, пока другие ожидают. Если мое обновление ничего не обновило, я знаю, что у кого-то еще есть «блокировка», и я жду или сдаюсь.

Мне нужно реализовать нечто подобное в PostgreSQL.

Вы бы сделали это так?

1 Ответ

1 голос
/ 20 марта 2019

Нет, я бы сделал это по-другому.

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

Это требование идеально подходит для консультативных блокировок PostgreSQL :

Вместо имени блокировки, например Singleton, вы выбираете номер блокировки, например, 1234.

Чтобы получить блокировку, запустите 

SELECT pg_advisory_lock(1234);

Чтобы снять блокировку, запустите 

SELECT pg_advisory_unlock(1234);

Это работает так же, как обычные блокировки базы данных, путем приостановки вызывающего процесса, если блокировка недоступна, и возобновления его, как только держатель блокировки снимает блокировку. Также есть функции для & ldquo; опроса & rdquo; консультативная блокировка доступности без блокировки.

Эти блокировки не зависят от транзакций PostgreSQL, они удерживаются до тех пор, пока не будут освобождены или пока не завершится сеанс работы с базой данных (поэтому опасности «сиротской блокировки» не существует).

Эти блокировки также не мешают работе в режиме автоочистки.

Это идеальный инструмент, если приложение хочет синхронизироваться с использованием методов базы данных.

...