Вопрос о COMMIT WORK

murmur

В таблице T есть запись F = 0, ID = 2

Один пользователь выполняет примерно следующий код

Code:

Поставить эксклюзивную блокировку (ENQUEUE)
  ...
  UPDATE T SET F = 1 WHERE ID = 2.
  COMMIT WORK.
Снять эксклюзивную блокировку (DEQUEUE)

Другой пользователь выполняет

Code:

Поставить эксклюзивную блокировку (ENQUEUE)
  ...
  SELECT 
    F
  FROM
    T
  WHERE
     WHERE ID = 2.
Снять эксклюзивную блокировку (DEQUEUE)

Первый пользователь выполняет свой код немного раньше, второй пользователь в это время ожидает (ENQUEUE с параметром WAIT)
Когда пользователь снимает блокировку, то второй пользователь устанавливает ее и выполняет SELECT. Вопрос - гарантировано
ли он получит запись со значение поля F = 1... или COMMIT WORK первого пользователя по каким-то внутренним причинам
может не успееть зафиксировать транзакцию в БД и второй пользователь сичтает F = 0?

ghost

не гарантировано. для таких гарантий есть дополнение к COMMIT WORK

Code:

commit work and wait

murmur

WAIT чего? Чего мы ждем? Между ENQUEUE/DEQUEUE не вызывается никаких CALL FUNCTION UPDATE TASK и т.п.
Есть просто расчетная часть и запись в БД.

Пономарев Артем

Странный вопрос, если честно. Ставить блокировку перед чтением записи - это зачем?
Если мне не изменяет память - уровень изолированности транзакций, который использует SAP - это RC.
Соответсвенно если данные закомитчены - то прочитает. Если еще нет - то не прочитает.

murmur

Я старался предельно ясно описать последовательность действий... посмотрите внимательнее на код

murmur

Второй пользователь выполняет такой код.... так будет точнее

Code:

Поставить эксклюзивную блокировку (ENQUEUE)
  SELECT 
    F
  FROM
    T
  WHERE
     WHERE ID = 2.
  ...
Снять эксклюзивную блокировку (DEQUEUE)

Пономарев Артем

Помоему я тоже вполне ясно ответил:
Если данные закомитчены - то прочитает. Если еще нет - то не прочитает. При уровне изолированности RC.
Но я был не прав. По умолчанию SAP использует уровент DR. Т.е. гарантированно.
Блокировки же здесь вобще не при чем.

murmur

Объясняю... первый пользователь снимет блокирровку после COMMIT WORK. Блокировка
гарантирует, что второй пользователь в это время будет ждать. После снятия блокировки возможны две
ситуации - либо второй пользователь считает F = 0, либо F = 1... Я считаю, что пользователь гарантировано считает
F = 1... Хочу понять, ошибаюсь ли я или нет... Прошу разъяснений

Пономарев Артем

Гарантированно будет 1.
Какие вам еще нужны разъяснения? Уровень изолированности - DR. Грязное чтение. Т.е. даже незакомтченные данные будут прочитаны селектом второго пользователя.

murmur

Какое грязное чтение! Прошу больше Вас не отвечать и не вводить людей в заблуждение

Пономарев Артем

Дорогой друг, все что я могу сделать в этой ситуации - это дать совет на будущее: прочитайте что-нибудь по теории СУБД.
Если рассматривать только связку клиент-сервер СУБД - то ответ я вам дал.
Что касается SAP - возможны варианты. Надо смотреть конкретную ситуацию. Обсуждать поведение системы в таких искусственных ситуациях и в вакуумной сфере - желания нет.

DKiyanov

2 murmur

Данную ситуацию можно решить с помощью блокировок базы данных (не путайте с логическими блокировками САП ENQUEUE, DEQUEUE)

Блокировка базы данных выставляется на записи БД по которым было выполнено update/insert
другой процесс не может сделать update/insert по тому же ключу что и в первом пока в первом не будет сделан commit.

т.е. реально во втором GUI будут висеть часики (ожидание) пока в первом GUI не будет сделан commit (тестировал лично)

В САПе есть такая конструкция select single for update...

murmur

Наверное стоит написать более понятно... ситуация не искусственная... пытаюсь применить оптимистичную блокировку...
Пользователь 1 выполняет редактирование документа не блокируя его. Затем, выполняет сохранение.
Если с момента взятия документа на редактирование, до его сохранения пользователь 2 изменил данные документа,
то пользователь 1 не может выполнить сохранение. Привожу более полный код и хочу узнать какие в нем есть недостатки

Пользователь 1

Взять документ на редактирование

Code:

GET TIME STAMP FIELD P_TS.

...

Спустя какое-то время попытаться сохранить документ

Code:

ENQUEUE NOWAIT.
  CLEAR V_TS.
  SELECT SINGLE V_TS FROM T WHERE ID = 5.
  IF P_TS > V_TS.
     ... useful work
    COMMIT WORK.
  ELSE.
    WRITE / 'Ошибка'.
  ENDIF.
DEQUEUE.

Пользователь 2 (с высоким приоритетом)

Code:

ENQUEUE WAIT.
   ... useful work
  COMMIT WORK.
  GET TIME STAMP FIELD V_TS.
  UPDATE T SET TS = V_TS WHERE ID = 5.
  COMMIT WORK.
DEQUEUE.

John Doe

Недостаток

Цитата:

Пользователь 1 выполняет редактирование документа не блокируя его.

murmur

Не блокировать документ - основное требование!

Правила форума

Вопрос о COMMIT WORK

Кто сейчас на конференции