VPF::Параллельный выбор данных из таблицы

Гость_Станислав

Дата 28.7.2005, 22:23 (ссылка)

(голосов: 0)

Загрузка ...

Unregistered

В строке

Код


update PHONES set LOCK_AGENT_ID = p_agent_id, LOCK_TIME = now() where PHONE_ID = (select min(PHONE_ID) from v_phone);

говорит: ERROR: relation "v_phone" does not exist

LSD

Дата 28.7.2005, 22:28 (ссылка)

(нет голосов)

Загрузка ...

Leprechaun Software Developer

Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538

Имя таблицы неправильное

Код

update PHONES set LOCK_AGENT_ID = p_agent_id, LOCK_TIME = now() where PHONE_ID = (select min(PHONE_ID) from PHONES);

--------------------

Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it.

Гость_Станислав

Дата 28.7.2005, 23:04 (ссылка)

(голосов: 0)

Загрузка ...

Unregistered

Так я тоже попробовал. На "READ COMMITTED" второй снова переписвает agent_id.
Да и потом, кажется тут в select нужно снова добавить lock_agent_id IS NULL, а то ведь выберет уже отработанный.

Код


update PHONES set LOCK_AGENT_ID = p_agent_id, LOCK_TIME = now() where PHONE_ID = (select min(PHONE_ID) from PHONES where lock_agent_id IS NULL);

иначе было бы, если бы действительно можно было выбрать из переменной v_phone

Гость_Станислав

Дата 29.7.2005, 00:18 (ссылка)

(голосов: 0)

Загрузка ...

Unregistered

Цитата(Stampede @ 28.7.2005, 00:24)

Да ну и запирай на здоровье. Там вся транзакция - на микросекунду

Похоже, что другого не остается... но, чисто принципиально, интересно, есть ли другой выход.

Stampede

Дата 29.7.2005, 00:56 (ссылка)

(нет голосов)

Загрузка ...

Гносеолог

Профиль
Группа: Участник Клуба
Сообщений: 963
Регистрация: 25.4.2005
Где: Calgary, Alberta, Canada

Репутация: нет
Всего: 144

Цитата

но, чисто принципиально, интересно, есть ли другой выход.

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

А вообще, разруливать конкурентные запросы средствами БД - то еще удовольствие. Гораздо удобнее управлять этими вещами извне, в серверном приложении. Если, конечно, таковое есть и если для него гарантируется монопольность доступа к данным.

--------------------

"If you want something done right, do it yourself"
По секрету: выучить английский - реально!

LSD

Дата 29.7.2005, 09:46 (ссылка)

(нет голосов)

Загрузка ...

Leprechaun Software Developer

Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538

Цитата

Похоже, что другого не остается... но, чисто принципиально, интересно, есть ли другой выход.

Без блокировок не обойтись. Но чтобы не блокировать таблицу целиком (в этот момент операторы которые уж получили свой номер, могут продолжать с ним работать не мешая нам), можно блокировать другой ресурс:

Код

select * from BLOCK_TABLE for update;
update PHONES set LOCK_AGENT_ID = p_agent_id, LOCK_TIME = now() where PHONE_ID = (select min(PHONE_ID) from PHONES where lock_agent_id IS NULL);
commit;

Или использовать встроенные средства наподобие Oracle-овского DBMS_LOCK.

--------------------

Гость_Станислав

Дата 30.7.2005, 14:26 (ссылка)

(голосов: 0)

Загрузка ...

Unregistered

Это отработали на другом форуме (Postgres):

Код


DECLARE
     v_phone_id INTEGER; 
     p_agent_id ALIAS FOR $1;

BEGIN
     SELECT INTO v_phone_id phone_id FROM phones WHERE lock_agent_id IS NULL LIMIT 1 FOR UPDATE;
     IF NOT FOUND THEN -- здесь отлавливаем, есть ли телефоны
           RETURN NULL; -- нет телефонов
     END IF;
     
    UPDATE phones SET lock_agent_id=p_agent_id WHERE phone_id=v_phone_id;
    IF FOUND THEN -- здесь отлавливаем, были ли обновлены строки
        RETURN v_phone_id;
    ELSE
        RETURN get_phone_id(p_agent_id); -- не успели, повторим попытку
   END IF;
END;

Работает, хотя принцип другой. Все же у меня есть сомнения по поводу рекурсивного вызова RETURN get_phone_id(p_agent_id). Мне кажется, что при одновременном запросе N'ым-количеством агентов, последнему прийдется вызывать эту функцию N-ое количество раз, предпоследний n-1, потом n-2 и так далее. И в конечном итоге, нагрузка на базу становится такой, что LOCK TABLE будет работать быстрее.

LSD

Дата 30.7.2005, 16:00 (ссылка)

(нет голосов)

Загрузка ...

Leprechaun Software Developer

Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538

А где здесь управление транзакциями? Клиент сам должен делать commit/rollback?

Цитата

Все же у меня есть сомнения по поводу рекурсивного вызова RETURN get_phone_id(p_agent_id). Мне кажется, что при одновременном запросе N'ым-количеством агентов, последнему прийдется вызывать эту функцию N-ое количество раз, предпоследний n-1, потом n-2 и так далее.

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

--------------------

0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| СУБД, общие вопросы \| Следующая тема »