Итак, что вам нужно:
- один и только один пользователь может иметь определенный идентификатор свободной части где-то на странице.Не разрешается, чтобы пользователь открывал форму и позволял заполнять детали, а затем отказывал процессу после отправки страницы, например, из-за номера, уже занятого другим пользователем.
- это уже исключаетстандартные механизмы, используемые в вершине.Проверка параллелизма и потери обновлений происходит только в точке обработки DML, обычно при отправке после вычислений и проверок.
- Я думал о том, чтобы отметить строку, которую пользователь выбирает для обновления.Однако это также должно быть отменено.Это нормально, пока пользователь действительно нажимает кнопку «Отмена», но вы не можете перехватывать другие события без дополнительных рамок.Даже тогда вы можете ловить только события браузера.Если пользователь будет сбивать процесс браузера или даже падать, что произойдет с отмеченной записью !?Он просто будет сидеть, ждать, пока разработчик исправит это, или не осознавая, что у них никогда не заканчивались цифры.
- возможно, можно было бы написать собственный механизм блокировки: создать блокировку загрузкистраница.Назовите эту блокировку после идентификатора выбранной детали, чтобы ее можно было проверить.Другой процесс загрузки на этой странице должен проверить блокировку входного идентификатора.Если блокировка существует, то потерпите неудачу и сделайте что-нибудь, например, перенаправление.Созданной блокировке также может быть дан тайм-аут, так что это фактически обеспечит резервное копирование для сбоя браузеров и компьютеров.Затем вам нужно будет снять эту блокировку, когда пользователь отменяет операцию.Нажатие на крошки или навигацию все еще не пойман, но вы можете рассчитывать на тайм-аут блокировки.Или используйте расширение фреймворка, такое как сохранение навыков перед выходом.Затем вы можете использовать процесс страницы, чтобы снять блокировку различных событий выхода (с помощью вызовов ajax).Решение все равно не будет на 100% оптимальным.Примером может служить ситуация, когда остается только 1 запись, и пользователь хочет что-то назначить.Однако по какой-то причине время блокировки все еще истекает, поэтому пользователь получает сообщение об ошибке, и поэтому считается, что идентификаторы не оставлены.Опять же, это можно решить, предоставив более подробное сообщение об ошибке, в котором говорится, что номера остались, но в данный момент заблокированы (« повторите попытку позже »? -: - /)
Эти вещи просто играют в моей голове.Я пробовал некоторые вещи, такие как «выбрать для обновления сейчас», но это не работает.Вероятно, потому что, как только блок был запущен, блокировка снята.
Я надеялся, что найду что-нибудь через Google, но на самом деле не радость.Я сам еще не сталкивался с этим требованием (пока?), Поэтому я также немного озадачен тем, как лучше всего это решить.
Редактировать: я помню, что где-то в последних 5 я использовал dbms_locksлет, и, возможно, вы должны попробовать это.DBMS_LOCK не может использоваться на apex.oracle.com, однако, и у меня нет прав на него в моей БД на работе (и ДБА здесь нет).Итак, давайте посмотрим на DBMS_LOCK и на этот пример .
Что бы вы сделали: создайте процесс заголовков onload-after и создайтеэксклюзивный замок там (эксклюзив, вы не хотите, конечно, поделиться чем-либо).Вы хотите, чтобы этот идентификатор был уникальным для выбранного идентификатора детали.Убедитесь, что у вас есть тайм-аут на блокировку (по умолчанию MAXWAIT = навсегда!) Или есть процесс отмены, чтобы снять блокировку, чтобы вы не столкнулись с проблемами при ее тестировании.
-- this is just a handle though, not the actual lock
dbms_lock.allocate_unique(lockname => 'lock_part_'||company1_part_id,
lockhandle => v_lockhandle,
expiration_secs => 300 -- 5 mins
);
-- request does the actual lock,
-- so this'll give errors when called for the same lockhandle
-- and a lock is already in effect
v_result := dbms_lock.request(lockhandle => v_lockhandle,
lockmode => dbms_lock.x_mode,
timeout => 0 -- fail instantly and don't wait to put a lock if already locked,
release_on_commit => true/false -- try both, not sure if it'll work with TRUE
);
release_on_commit
Установите для этого параметра значение TRUE, чтобы снять блокировку при фиксации или откате.
В противном случае блокировка удерживается до тех пор, пока она не будет явно снята илидо конца сеанса.
Если все в порядке, другой сеанс не сможет заблокировать тот же идентификатор, тогда из-за созданной вами блокировки.Перехват ошибок вам придется попробовать самостоятельно, но это не должно быть трудным тестированием для существующей блокировки и предоставлением адекватной обратной связи для ошибок.
DBMS_LOCK.request Возвращаемые значения
Таблица 70-10. Возвращаемые значения функции REQUEST
Возвращаемое значение Описание
0 Успех
1 Тайм-аут
2 Deadlock
3 Ошибка параметра
4 Уже собственная блокировка, указанная вid или lockhandle
5 Недопустимый дескриптор блокировки
Мне нравится расширять апекс, но если вам придется сильно постараться из-за одной страницы и иметь много разных процессов, всеобычай для этой одной страницы ... Может быть, есть простой способ, я просто не могу увидеть это сам (пока).