Re: SELECT FOR UPDATE

Поиск
Список
Период
Сортировка
От ok@mochamail.com (Cody)
Тема Re: SELECT FOR UPDATE
Дата
Msg-id b7be5f20.0108261250.283023a6@posting.google.com
обсуждение исходный текст
Ответ на Re: SELECT FOR UPDATE  (Jan Wieck <JanWieck@Yahoo.com>)
Список pgsql-general
I just finished reading Bruce M's book, so this thread confuses me,
esp. Jan's posts.  I take full heed of the need for application level
user/thread management, but I was interested in using a parallel
set-up in PG (however redundant that might be).  Now that Jan has
discounted "SELECT...FOR UPDATE," is the best alternative using a
central locking table (perhaps in conjunction with LISTEN & NOTIFY)?
Ironically, anyone who suggested using application level transactions
would be torn apart at any of the places I've worked at--but that
seems to be the gist of this thread.  I cannot see a way to avoid
deadlocks without an application level transaction component, since
the central locking table idea would similarily lock the record
forever if the first transaction failed to COMMIT or ROLLBACK.

What is the saying:  To the beginner, there are many options.  To the
wise, there are few.

В списке pgsql-general по дате отправления:

Предыдущее
От: Jacek Lampart
Дата:
Сообщение: Wanted: Postgres 6.5.3 dll
Следующее
От: "satish rao "
Дата:
Сообщение: Create table syntax