Совместное использование одной таблицы

← →
Jeer © (2006-11-24 11:44) [80]

Все зависит от того, что считать под блокировкой.

Блокировка сервером кортежа во время транзакции совершенно нормальна, именно так и работают блокировочники.
Если сдохнет приложение, то блокировка автоматически снимется.

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

Короче говоря, надо уточнять какой уровень процессов обсуждается - уровень СУБД или уровень бизнес-процессов.

Пример.
Менеджер работает с клиентом (заказом клиента) и "ведет" его в течение м.б. нескольких дней, месяцев.
В этом случае должно выполняться резервирование (закрепление) клиента за конкретным менеджером. Это можно назвать блокировкой клиента для других менеджеров. Разумеется, здесь нет никакой транзакции в смысле СУБД, а может быть только откат (сторнирование) операции тем же менеджером или главным менеджером.

Как реально выполняется резервирование ?
У клиента X есть метка (поле IDM) - ID менеджера.
Например ID=0 - клиент ни за кем не закреплен и далее по номерам менеджеров.
Менеджер, обрадовавшись клиенту спешит закрепить его за собой.
Открывает форму с клиентами и ищет такового.
В зависимости от реализации процесса могут быть показаны все клиенты или только свободные клиенты.
Предположим реализация такова, что показаны все клиенты и не визуализированы признаки закрепленности.
Менеджер выбирает клиента X и нажимает кнопочку "Закрепить".
Приложение выполняет операцию с SQL командой:
UPDATE CLIENTS SET IDM = 1 WHERE ( ID = X ) AND ( IDM = 0 );

В данном случае, если клиент не занят, то происходит перезапись IDM с 0 на 1, если нет - то и не перезапишет.
По DBErrors приложение извещает менеджера о неудаче, т.е. о занятости клиента.

Прблема зависших блокировок клиента в данном случае может быть решена только административными и логическими методами.

← →
ANB © (2006-11-24 12:00) [81]

> Приходится администратору лезть на сервер и снимать блокировку.

Достаточно убить мертвую сессию.

> Вопрос: как мне узнать на этот период времени, что именно
> ЭТИ 3 места заняты, и мне даже не стоит щелкать по ним мышкой,
> чтобы отложить в другой заказ?

Время от времени рефрешить экран (слишком часто по таймеру - некузяво, оптимально - перед началом резервирования). А при клике по месту в целях резервирования проверять, что оно еще не захвачено другим кассиром, а если успело захватится - перекрашивать и выдавать немодальное сообщение. тогда никого напрягать не будет.

← →
Anatoly Podgoretsky © (2006-11-24 12:04) [82]

> clickmaker (24.11.2006 11:30:19) [79]

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

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

← →
clickmaker © (2006-11-24 12:05) [83]

> Время от времени рефрешить экран

это клиентское решение. Интересует, как на сервере это оформить. Сам же намекнул, что через доп. поле - это вчерашний век.
А как тогда? Статус-то места где хранить, если не в поле?

← →
clickmaker © (2006-11-24 12:07) [84]

> [82] Anatoly Podgoretsky © (24.11.06 12:04)
> > clickmaker (24.11.2006 11:30:19) [79]
>
> Резервирование и они должны быть отображены другим цветом,
> поскольку и них нет статуса Свободные/Проданые, но почему
> через блокировку это надо делать не пойму, надо сменить
> для данного конкретного случая (места в в зале) статус на
> Зарезервировано и все

Господи, так а я об чем?
Ну неправильно я сказал "блокировка", но поправился уже ведь

← →
ANB © (2006-11-24 12:14) [85]

> Сам же намекнул, что через доп. поле - это вчерашний век.
>
> А как тогда? Статус-то места где хранить, если не в поле?
>

Блокировка через поле - вчерашний век. А резервирование через него и делается. Нужно только в update обязательно вписать условие, проверяющее, что долей секунды раньше место не захапал другой оператор.
Короче - Jeer все объяснил.
Кистате, в элементарном случае с 3-мя статусами Свободно/Оформляется/Продано можно и на блокировках все замутить - только проблема с определением - ктож хапнул то ? Хотя конкретному кассиру обычно это и не нужно.

← →
Anatoly Podgoretsky © (2006-11-24 12:16) [86]

> ANB (24.11.2006 12:00:21) [81]

Продажа билетов, это то место где можно делать обновление схемы как по таймеру, так и по клику и сообщений не надо выдавать, просто перерисовать. Сообщение нужно когда удалось захватить (зарезервироваться). Можно и клиентку показывать на втором мониторе туже схему, как жест доброй воли к клиенту.

← →
Anatoly Podgoretsky © (2006-11-24 12:17) [87]

> clickmaker (24.11.2006 12:05:23) [83]

На сервере ничего не надо делать, на сервере всегда актуальное состояние.
Если сервер начинает что то рассылать, то он превращается в клиента. Это по определению клиент/сервер.

← →
Anatoly Podgoretsky © (2006-11-24 12:19) [88]

> clickmaker (24.11.2006 12:07:24) [84]

Так тебе постоянно и долдонят, что данный термин неправильный и ведет только к непониманию. При его использовании как минимум надо брать в кавычки, а лучше использовать более правильный термин.
Конечно русский язык гибкий, слишком гибкий.

← →
ANB © (2006-11-24 12:23) [89]

> так и по клику и сообщений не надо выдавать, просто перерисовать

Не, с сообщением удобнее. Только его обязательно немодальным надо делать - что нибудь вроде статусной строки внизу формы. В случае проблем - выводить туда текст и делать красным. Если все ОК - выводить об этом текст и делать его черным. Не напрягает - не хочешь, не читай, и повышает информативность.

← →
clickmaker © (2006-11-24 12:26) [90]

Ну хорошо, если все согласились, что дело только в терминологии, и данное решение имеет место быть, то я еще раз прошу уважаемого MsGuns объяснить мне
1) в чем мое непонимание технологии "клиент-сервер"
2) почему я должен обратить свое внимание именно на понятие "транзакции"
3) почему техника, которую я использую - "из песка и алебастра", и какие есть альтернативы. Именно для данной задачи

Обвинения нужно аргументировать

← →
Jeer © (2006-11-24 12:36) [91]

> clickmaker © (24.11.06 12:26) [90]

Я уже пояснил, что для управлением блокировок в бизнес-процессах применение транзакций, как правило, недопустимо, т.к. это длительные процессы.

Транзакции совершенно необходимы в конкурирующих (параллельных) обращениях, когда логической единицей служат наборы операций (SELECT, INSERT, UPDATE,DELETE).

Скорее всего между вами произошло недопонимание терминов и кто-то погорячился.

← →
clickmaker © (2006-11-24 12:37) [92]

> для управлением блокировок в бизнес-процессах применение
> транзакций, как правило, недопустимо, т.к. это длительные
> процессы

так я вроде на протяжении всего разговора как раз об этом и говорю...

← →
Sl_RO (2006-11-24 13:09) [93]

clickmaker © (24.11.06 12:05) [83]
через доп. поле - это вчерашний век
Если поле в базе - то ДА.
Если "виртуальное" поле (вычислимое на сервере-приложений в 3х звенке)- то НЕТ: синглетон с блокировками (in mem) и клиенты с калк полем

← →
clickmaker © (2006-11-24 13:11) [94]

> Если "виртуальное" поле (вычислимое на сервере-приложений
> в 3х звенке

вычислимое на основании чего?

← →
Anatoly Podgoretsky © (2006-11-24 13:25) [95]

> ANB (24.11.2006 12:14:25) [85]

set fld=value1 where fld<>value2

Гарантирует, что две одновременные транзакции не смогут привести в не консистентное состояние

← →
Anatoly Podgoretsky © (2006-11-24 13:28) [96]

> ANB (24.11.2006 12:23:29) [89]

Против статустной строки таких возражений нет, кроме дублирование, при щелчке сразу будет нужная информация прямо в месте щелчка. Цвет сменится и не только у данного места, а у всех измененых, а что бы не перегружать запрос, то можно использовать поля типа TimeStamp по терминологии МS SQL сервер, сейчас рекомендуют использовать синоним ROW_VERSION

← →
Anatoly Podgoretsky © (2006-11-24 13:30) [97]

> Jeer (24.11.2006 12:36:31) [91]

Транзакция все равно есть, только неявная, даже для SELECT
но явная нужна именно только пачки операций.

← →
Anatoly Podgoretsky © (2006-11-24 13:31) [98]

> Sl_RO (24.11.2006 13:09:33) [93]

Если трехзвенка то много вопросов решается, в том числе и состоянием.

← →
Jeer © (2006-11-24 13:36) [99]

> Anatoly Podgoretsky © (24.11.06 13:30) [97]

> Транзакция все равно есть, только неявная,

Это-то понятно, но мы пока не лезем в потроха движка СУБД.
Атомарной должна быть любая операция, в том числе и SELECT.
Надо будет - залезем:)

← →
SlymRO (2006-11-24 13:43) [100]

clickmaker © (24.11.06 13:11) [94]
вычислимое на основании чего?
На основании таблицы блокировок (ТБ) на сервере приложений (СП):
Клиент запрашивает данные у СП, СП к возвращаемым данным прицепляет доп. поле с вылукаплеными (о как сказал) значениями из ТБ. ТБ обязательно в памяти, но можно и на диск сбрасывать, но тогда при запуске сервера обязательно ее очищать.

← →
clickmaker © (2006-11-24 14:04) [101]

> [100] SlymRO (24.11.06 13:43)
> clickmaker © (24.11.06 13:11) [94]
> вычислимое на основании чего?
> На основании таблицы блокировок (ТБ) на сервере приложений
> (СП):

мы говорим про клиент-сервер. У нас нету сервера приложений

← →
Anatoly Podgoretsky © (2006-11-24 14:07) [102]

> Jeer (24.11.2006 13:36:39) [99]

Атомарной, отдельная операция атомарно, поэтому явная транзакция не нужна.
Пакет не атомарен, поэтому явно.

← →
Anatoly Podgoretsky © (2006-11-24 14:08) [103]

> SlymRO (24.11.2006 13:43:40) [100]

Естественно сервер приложений может вести свои списки состояний.

← →
Jeer © (2006-11-24 14:08) [104]

> Anatoly Podgoretsky © (24.11.06 14:07) [102]

Я о том же.
Еще лучше - когда трое о том же:)

← →
Anatoly Podgoretsky © (2006-11-24 14:45) [105]

> Jeer (24.11.2006 14:08:44) [104]

Дык основы :-)

>clickmaker © (24.11.06 12:26) [90]
>Ну хорошо, если все согласились, что дело только в терминологии, и данное решение имеет место быть, то я еще раз прошу уважаемого MsGuns объяснить мне

Дался Вам этот "Ганз" ;))

>1) в чем мое непонимание технологии "клиент-сервер"

потому что нет понимания "транзакций"

>2) почему я должен обратить свое внимание именно на понятие "транзакции"

Потому что это "сердце" любого сиквель-сервера

3) почему техника, которую я использую - "из песка и алебастра", и какие есть альтернативы. Именно для данной задачи

Дело не в задаче, а в подходе. Ваш подход основан на фиксации виртуальных событий ("занято", "свободно"..) как реальных сущностей (полей БД) - а это уже по сути "локалка" со всеми вытекающими, о чем тут уже горы наговорено. Этого делать нельзя? ибо Вы пытаетесь проблемы пассажиров и водителей повесить на автодорожников - из этого ничего хорошего не получится, разве что в каком-нибудь Мухосраснске с единственной дорогой, десятью дворами с имеющимися в наличии тремя мотоциклами и шестью велосипедами в общей сложности.

Обвинения нужно аргументировать

Я Вам приводил примеры, какие еще Вам нужны аргументы ? Или Вы думаете? что с точки зрения сиквель-сервера "Опербанк" и "Два кассира" есть? как говорят в Одессе? "две большие разницы" ?

ЗЫ. Еще раз повторяю, что если в моем "наезде" Вас больше всего покоробил акцент на значок, то я приношу извинения и забираю свои слова назад? этого будет достаточно для того, чтобы Вы перестали обмывать мои косточки ? ;)

> как реальных сущностей (полей БД) - а это уже по сути "локалка"
> со всеми вытекающими

Во - вы тоже за использование по возможности родных блокировок ?

>clickmaker © (24.11.06 17:55) [108]
>из какого моего поста это следует?

Да практически с первого Вашего вступительного поста Вы начинаете развивать технологию блокировок, которые есть фикция, "муляж" в клиент -серверных платформах.
Так настойчиво навязываемый Вами пример "двух кассиров", где будто бы надо чего-то разруливать и кого-то о чем-то оповещать, как раз и не нуждается ни в каких блокировках, а если такие используются разработчиком (но никак не сервером), то это уже результат не слишком высокой его (разработчика) квалификации и недостатка опыта.
Вам целым кагалом пытались объяснить Ваши заблуждения, советуя и литературу, и присмотреться к хорошо зарекомендовавшим себя системам, но Вы почему-то из всех выделлил MsGuns инастойчиво пытаетесь призвать его "к ответу".
Мне это не нужно. Если Вам в этой ветке важнее всего сохранить "честь мундира", а не поучиться у тех, кто элементпрно грамотнее или опытнее Вас в этом вопросе, то я ошибся, встряв в нее. Поэтому в третий и последний раз приношу свои извинения и прощаюсь.

> [109] MsGuns © (25.11.06 23:12)

Ну хорошо. Вот мои первые посты

>Т.е. либо есть некий сервис, который оповещает остальных, что некто Вася >поменял запись 1. После 2 варианта. Либо переоткрытие датасета, либо >вообще не используется грид, а например ListView. Тогда можно >индивидуально управлять записями по ID.
>Еще вариант, если записей не слишком много, и жесткий риалтайм не >нужен, то по таймеру обновлять табличку на клиенте.

>Для особо критичных данных иногда применяют следующее. Грид >редактировать запрещают вообще. Только специальной формой. При >открытии формы запись блокируется. Все остальные после этого получают >либо отлуп, либо предложение открыть инфу для чтения. Эта идея с успехом >используется в офисных приложениях (ворд, эксель).
>Форма закрылась - блокировку снимаешь

Здесь я предлагал использовать технологию, которую Анатолий потом назвал "резервирование". Согласен, я неверно использовал термин, что видимо и вызвало у вас такую бурную реакцию.
Но не подумали же всерьез, что я предлагаю на открытие формы блокировать запись средствами сиквела или (что еще хуже) стартовать транзакцию, а при закрытии накатывать или откатывать?
Я может и не совсем заслуженно ношу значок, но я не настолько туп, знаете...

> clickmaker (26.11.2006 13:21:50) [110]

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

> ак настойчиво навязываемый Вами пример "двух кассиров",
> где будто бы надо чего-то разруливать и кого-то о чем-то
> оповещать, как раз и не нуждается ни в каких блокировках

Там где два, там может быть и двадцать два. Причем тут количество? Важен принцип. Я предлагал всего лишь использовать некое поле для обозначения статуса ОБЪЕКТА, именно объекта, а не записи. Зарезервирован, свободен, продан и т.д. - набор состояний зависит от предметной области. Я сам противник использования напропалую каких-либо специфичных для серверов БД фич, о чем, кстати, здесь упоминал.
Вы же налетели как коршун, даже не попытавшись разобраться, о чем речь. Вот что обидно, а не "честь мундира"....

> clickmaker (26.11.2006 18:13:52) [112]

А ты чего то другого ожидал от публичного форума?

> [113] Anatoly Podgoretsky © (26.11.06 18:28)
> > clickmaker (26.11.2006 18:13:52) [112]
>
> А ты чего то другого ожидал от публичного форума?

Я начинаю понимать, почему америкосы обходят нас по части ПО. Английский язык допускает гораздо меньше неоднозначностей в терминах, и они быстрее договариваются... ))

> [112] clickmaker ©

только не объекта, а сущности :), это единственный реальный способ отслеживания ее состояния на распределенных системах и системах без поддержки постоянного соединения до сервера, самый главный его плюс - он не зависит от особенностей того или иного хранилища данных...

> [103] Anatoly Podgoretsky ©

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

> clickmaker (26.11.2006 18:36:54) [114]

Конечно, один перевод термина потоки чего стоит.

Совместное использование одной таблицы Найти похожие ветки