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

То что Вы написали или процитировали не что чтобы неверно, но бессмысленно с практической точки зрения.
Те транзакции, которые не являются конфликтующими с точки зрения PostgreSQL'ного READ COMMITED, легко могут нарушать необходимый для 1C SERIALIZABLE.

Кстати, чтобы Вы понимали ситуацию, "собственный менеджер транзакционных блокировок 1С:Предприятия" писал я.

Раз пошла такая пьянка. Может объясните чем корректный откат и перепроведение плохой метод?

Да, есть проблема с внешним последействием (если вы скажем e-mail шлете), но его вообще лучше в асинхронный поток выносить, так как это точка отказа которая может повесить всю транзакцию со всеми вытекающими. Больше я придумать не могу. Собсно потому как часто использовали такой метод и практически всегда все было ОК.

ilejnNitro_Junkieчем корректный откат и перепроведение плохой метод?


Он не то чтобы плохой метод, он скорее вообще не метод, который может предложить Платформа.
Эти операции не будут прозрачны для писателя конфигурации.

Почему не прозрачны. Все что происходит в транзакции остается в транзакции. В конечном итоге если вы отменяете проведение, то все изменения внутри проведения "откатываются", и разработчик же это понимает. Что сложного в понимании того что платформа может при необходимости сама откатить транзакцию и запустить заново (то есть грубо говоря самопроизвольно выполнить cancel в определенных местах)

ilejnNitro_Junkie, что должно вызвать решение об отмене транзакции? Факт изменения некоторой таблицы?

Например, если СУБД кинула update conflict (то есть с начала транзакции, кто-то уже поменял записываемое значение), или unique violation (когда в одну таблицу 2 раза ключ добавляют)...

ilejnNitro_Junkieпропущено...


Например, если СУБД кинула update conflict (то есть с начала транзакции, кто-то уже поменял записываемое значение), или unique violation (когда в одну таблицу 2 раза ключ добавляют)...

Если бы СУБД, работающая в режиме изоляции READ COMMITED, могла детектировать все нарушения уровня SERIALIZABLE, то Вашу идею можно было бы реализовать.

Естественно речь идет о работе СУБД в режиме изоляции уровня SERIALIZABLE, в read commited update conflict'ов ЕМНИП вообще не бывает.

Для меня просто загадка нахрена 1С мало того что решил переписать стандартные механизмы СУБД (а обеспечение целостности одна из самых важных их функций), так еще это решили сделать в ручном режиме и переложить всю ответственность на разработчика. Причем с первым пунктом понятно, они все переписывают, у них это видимо в крови, а вот со вторым... Причем что самое забавное большинство 1С разработчиков этого даже не понимают (что на них возложили абсолютно не нужную ответственность).

ilejn[quot Nitro_J
Естественно речь идет о работе СУБД в режиме изоляции уровня SERIALIZABLE

В PostgreSQL до недавнего времени не было работающего SERIALIZABLE.[/quot]

Ну Repeatable Read был. Его в 97% случаев (например те же остатки) более чем достаточно. А SERIALIZABLE в крайнем случае виртуальными агрегациями можно было сэмулировать...

ilejnЯ попробую вспомнить, чем был нехорош SET TRANSACTION SERIALIZABLE.
Но что-то с ним было не так.

Я могу сказать чем он нехорош, особенно в случае платформ.

Любая программа де-факто работает в двух парадигмах - процедурной и SQL. Так вот когда вы начинаете транзакцию, вам нужно обеспечить ее откат в обоих парадигмах. И если в SQL это достигается автоматически, то в процедурной все нужно делать руками. Например если вы используете pooling временных таблиц, то при откате транзакции у вас и все действия с временными таблицами откатятся, а значит их надо будет вручную отслеживать и очищать из пула. Тоже самое касается любых кэшей, "локальных" переменных и т.п. Плюс ко всему нужно абсолютно корректно обрабатывать исключения в любом месте где внутри может быть DML (то есть по сути везде). И если ошибки можно классифицировать как нестандартную ситуацию и грубо говоря "забить" на некоторые побочные эффекты, то с update conflict'ами такое не прокатит.

В общем, ИМХО, на C++ с не самой удобной обработкой исключений, без сборщика мусора и т.п. просто "кишка оказалась тонка".

PGSQLAnonymousА любую программу, которая этого не делает, нужно, грубо говоря, выбросить. ;)

Ну 1Сом как видите пользуются...

Хотя бы потому, что нормальной обработки DEADLOCK-ов в ней почти наверняка тоже нет.


Так DEADLOCK то как раз теоретически можно считать "ошибкой" - "недетерминированный" (цикличный) порядок записи \ чтения. С UPDATE CONFLICT так не получится.

PGSQLAnonymousТак они же удобной обработкой исключений, наоборот, хвалятся (как я слышал), RAII там какое-то есть. ;)

В последних версиях. Но в любом случае это субъективная инфа, от тех кто, скажем, на C++ и Java писал. Так что просто догадка :)