powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Долгие транзакции - Короткие транзакции
12 сообщений из 62, страница 3 из 3
Долгие транзакции - Короткие транзакции
    #32966900
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
funikovyuriтекущая реализация транзакций в РСУБД оптимизирована для какой-то одной стратегии. Обычно это пессимистическое блокирование всех используемых ресурсов в зависимости от уровня изоляции.
Вот это я не совсем понял. Оптимистическая блокировка в транзакциях реализуется ничуть не хуже пессимистической - разве что нет готовой поддержки. Версионники, конечно, могли бы дать здесь инструмент контроля изменений, более удобный чем ручной timestamp.
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32966914
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Оптимистическая блокировка в транзакциях реализуется ничуть не хуже пессимистической

Самим ядром СУБД она никак не реализуется. Т.е. это вне его компетенции. А timestamp - это уход от философии разделения внутреннего и внешнего представления данных. Т.е. это зависимость от данных! Вот примерно о чем я говорю
Код: plaintext
1.
2.
3.
4.
begin tran (optimistic, read commited)
...

commit tran
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32967210
beginner123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 MasterZiv:
авторА если это реально нужно - реализация внетранзакционных блокирово уровня приложения достаточно проста и прозрачна, чтобы ее обсуждать. Варианты какжется предлагались, если нет - в сети их описано достаточно много.

А можно хотя бы пару ссылок на реализацию "внетранзакционных блокировок уровня" ?
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32967858
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
funikovyuriОптимистическая блокировка в транзакциях реализуется ничуть не хуже пессимистической
Самим ядром СУБД она никак не реализуется.
В ней по большому счету нечему реализоваться ядром СУБД. Для этого надо пойти в сторону Access, PowerBuilder или других средств автогенерации SQL-я.

Грубо говоря,

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
-- пессимистическая блокировка
select * from mytab where id = :id for update wait  5  ;
....
update mytab set value = :newvalue where id = :id ;
commit ;

-- оптимистическая блокировка
select * from mytab where id = :id
....
update mytab set value = :newvalue where id = :id and value = :oldvalue ;
if sql%notfound 
  then raise_application_error ( - 20100 , 'Облом' ) ; 
  else commit ;
end if ;

Единственное, что могла бы база - заменить последнее на что-нибудь типа

Код: plaintext
1.
2.
update /*+ IF_NOT_CHANGED */ mytab set value = :newvalue where id = :id ;
commit ;

Было бы удобно, не спорю.
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32969094
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PB генерит запрос только на изменившиеся записи/поля, поэтому если я у 2 записей изменил 2 разных поля, то для каждой записи будет соотвествующий UPDATE только на изменившиеся поля, а в WHERE помимо ID будут поставлены на сравнение со старыми значениями эти поля или все, которые я явно указал для DataWindow. Вообще в PB на DataWindow достаточно много настроек модели поведения сохранения информации в БД, вплоть до изменения ключевого поля. Если же ничего из предложенных вариантов не устраивает, PB всегда можно попросить проводить изменения через собственные ХП. По моему тут достаточно простора для потребностей и фантазии.
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32969122
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUS

угу - только в where все равно будут ВСЕ поля... Иначе никакого смысла в этом нет
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32969139
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
funikovyuri ASCRUS

угу - только в where все равно будут ВСЕ поля... Иначе никакого смысла в этом нет
В WHERE будет в зависимости от выбранной опции:
Key columns

Key and Updateable columns

Key and Modified columns
Нужные поля можно ручками включить в список "Updateable columns" для соотвествующе выбранного режима.
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32969148
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну 1 - это понятно, 2 - о чем я и говорю, 3 - вот его практическое назначение для меня загадка :)
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32970950
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSPB генерит запрос только на изменившиеся записи/поля, поэтому если я у 2 записей изменил 2 разных поля, то для каждой записи будет соотвествующий UPDATE только на изменившиеся поля, а в WHERE помимо ID будут поставлены на сравнение со старыми значениями эти поля
Это замечательный путь к рассогласованию данных внутри одной записи.

ASCRUSили все, которые я явно указал для DataWindow.
А к этому относятся те минусы, о которых я говорил.

ASCRUSВообще в PB на DataWindow достаточно много настроек модели поведения сохранения информации в БД, вплоть до изменения ключевого поля.
Хм. Это по-моему, рядовое требование.

ASCRUS Если же ничего из предложенных вариантов не устраивает, PB всегда можно попросить проводить изменения через собственные ХП. По моему тут достаточно простора для потребностей и фантазии.
Хм. Речь, кажется, идет не о преимуществах использования PB :)
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32970963
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
funikovyuri3 - вот его практическое назначение для меня загадка :)
3 - это путь "минимальной блокировки" в абсолютно нормализованной базе. В этом случае максимальна вероятность итогового успеха, поскольку две сессии могут в параллель редактировать разные поля записи. Цена этого - очень строгие требования к независимости данных.
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32973177
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
блин....сколько слов вокруг сто раз пережёванной темы !
Притом, что это далеко не первый флейм про блокировку документов.
Делайте самодельную блокировку и Вы сможете :
* увидеть, кто и когда занял документ;
* увидеть с какой машины занят документ;
* каким именно действием занят документ;
* блокировку на определённые действия и на длительное время;
* ещё многое другое, что Вам придёт в голову :)

На уровне серверных блокировок всё перечисленное выполнить невозможно.
...
Рейтинг: 0 / 0
Долгие транзакции - Короткие транзакции
    #32973539
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVДелайте самодельную блокировку и Вы сможете :
* увидеть, кто и когда занял документ;
* увидеть с какой машины занят документ;
* каким именно действием занят документ;
...
На уровне серверных блокировок всё перечисленное выполнить невозможно.

Возможно, возможно. По крайней мере для MSSQL. Хотя и не сказать, чтобы просто.

Вообще же, MasterZiv отчасти прав в том, что использование любого механизма блокировок в ИС - хоть самодельных, хоть серверных - надо начинать с тщательной минимизации возможности возникновения таких блокировок. Т.е., часто полностью избежать их нельзя, но значительно уменьшить кол-во можно. Например, в примере предложенном softwarer, для примечания вряд ли обязательно блокировать документ.


Nobody faults but mine... (LZ)
...
Рейтинг: 0 / 0
12 сообщений из 62, страница 3 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Долгие транзакции - Короткие транзакции
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]