Продажа билетов несколькими кассирами

← →
Anatoly Podgoretsky © (2006-09-27 16:03) [40]

Не надо ничего блокировать, надо резервировать для продажи. Срок резервирования ограничить.

← →
alabama01 (2006-09-28 01:22) [41]

> Sergey13 © (27.09.06 08:28) [36]

> Придумываешь ты. 100 автобусов в день по 60 человек 365
> дней в году = 2190000 записей. Детский лепет при наличии
> индексов.

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

> evvcom © (27.09.06 08:28) [37]

> Т.е. сервер асинхронно извещает всех своих подписчиков (кассиров)
> о проданном месте? Хорошая фича.

Без нее вообще беда.

> MsGuns © (27.09.06 13:26) [38]
>
> Все эти "лочания" незаметно превращаются в "глючения".
> Прежде чем решать подобные проблемы неплохо хотя б в общих
> чертах познакомиться с подобными системами. Хотя бы просто
> поинтересовавшись как функционирует бронирование в гостинницах
> например у администратора. Или в тех же ж/д кассах.
> Ключевое слово - "резервирование" или его варианты.

Да я, собственно, поэтому и задал вопрос на форум. Да и как осуществить это резервирование, если билеты продаются как горячие пирожки?

> Desdechado © (27.09.06 15:48) [39]

Для скорости.

> Anatoly Podgoretsky © (27.09.06 16:03) [40]

Как?

← →
alabama01 (2006-09-28 03:04) [42]

Решение найдено следующее:
пишем dll active-x, которая ,будет работать на сервере и ХП1, которая будет ее запускать. Регистрируем на сервере dll.
Далее:
1) форма продажи при открытии, в отдельном потоке, создает ожидание события Event1;
2) после выбора места в комбобоксе со свободными местами запускаем ХП1 с передачей в параметрах id рейса и номера выбранного места.
3) ХП1 запускает в dll функцию, которая смотрит наличие данного свободного места и, если оно действительно свободно, то записывает его как занятое, и возвращает новое число со списком свободных мест, если же оно уже занято, тогда - 0. Все это описано в критической секции.
4) Если результат не 0, тогда функция сбрасывает событие Event1.
5) Форма продажи получает сброс события и новое число с местами, затем смотрит, если на ней есть такой рейс, то пересчитывает число в места и перересовывает комбобокс с новыми свободными местами.
6) форма продажи снова создает ожидание события Event1;

← →
atruhin © (2006-09-28 09:24) [43]

А что будет при обрыве сети, и если место заблокированно?

← →
Sergey13 © (2006-09-28 09:27) [44]

> [42] alabama01 (28.09.06 03:04)

А сколько у тебя кассиров?

← →
alabama01 (2006-09-28 10:10) [45]

> atruhin © (28.09.06 09:24) [43]
>
> А что будет при обрыве сети, и если место заблокированно?
>

Я несколько упрощенно описал. Помимо описанного, ХП1 пишет это место, id рейса, и id копии программы в таблицу зарезервированных мест.
Каждая копия программы пишет себя с определенной периодичностью в специальную таблицу. Триггер этой таблицы смотрит все записи, у которых превышен период ожидания и считает эту копию "отломившейся". Соответственно удаляет все последствия потери связи.

> Sergey13 © (28.09.06 09:27) [44]
>
> > [42] alabama01 (28.09.06 03:04)
>
> А сколько у тебя кассиров?

Пока трое. Количество будет расти.

← →
Sergey13 © (2006-09-28 10:25) [46]

> [45] alabama01 (28.09.06 10:10)

> Пока трое. Количество будет расти.

До 5? До 6?
Я бы не стал заморачиваться на вариант из [42] alabama01 (28.09.06 03:04), а сделал, как советуют, нормальное резервирование.

← →
MsGuns © (2006-09-28 12:12) [47]

>alabama01 (28.09.06 03:04) [42]
>Решение найдено следующее: пишем dll active-x..
...
>Я несколько упрощенно описал.

Засстрелиться...

← →
Плохиш © (2006-09-28 13:27) [48]

> Засстрелиться

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

← →
ANB © (2006-09-28 14:12) [49]

Я бы посмотрел в сторону доводки интерфейса и отказа от комбобокса. Пример - я прошу 2 билета РЯДОМ. Однако, если не учитывать конфигурацию мест, то 2 места подряд по номерам не всегда будут рядом. Видел я кассу в кинотеатре. Там прямо схема зала и кассирша кликает по свободным местам, резервируя места. Если у нее старая картинка, то при клике на уже занятом другой кассиршей месте, вываливается мессага и ячейка перекрашивается. Резервированные места кладутся в корзину и при продаже уже заносяться в билеты. Очень удобно.

← →
Anatoly Podgoretsky © (2006-09-28 19:39) [50]

Визуальный выбор всегда удобен, и вот для этой схемы подходит оповещение клиентов. Зарезервирован/продан/возвращен. Для продажи в кинотеатрах особенно, для продажи на поезда требуется делать немного иначе, поскольку вагонов много и они разные.

← →
alabama01 (2006-09-29 01:41) [51]

> Sergey13 © (28.09.06 10:25) [46]
> Я бы не стал заморачиваться на вариант из [42] alabama01
> (28.09.06 03:04), а сделал, как советуют, нормальное резервирование.
>

Не больше, наверное. Но сообщения о занятости места сильно досаждают. Даже мне, когда отлаживал.

> MsGuns © (28.09.06 12:12) [47]
>
> Засстрелиться...

Этот алгоритм только кажется сложным. При ближайшем рассмотрении - все не так страшно. Зато нет никаких дополнительных сообщений о недоступности выбранного места. Выбранное - всегда есть. И таблицы лочить не надо.

> Плохиш © (28.09.06 13:27) [48]

На экране ничего не мелькает.

> ANB © (28.09.06 14:12) [49]
>
> Я бы посмотрел в сторону доводки интерфейса и отказа от
> комбобокса.

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

> Anatoly Podgoretsky © (28.09.06 19:39) [50]
>
> Визуальный выбор всегда удобен, и вот для этой схемы подходит
> оповещение клиентов. Зарезервирован/продан/возвращен. Для
> продажи в кинотеатрах особенно, для продажи на поезда требуется
> делать немного иначе, поскольку вагонов много и они разные.
>
>

Вот и я о том же.

← →
MsGuns © (2006-09-29 11:54) [52]

>alabama01 (29.09.06 01:41) [51]
>Этот алгоритм только кажется сложным.

Я не сказал, что он сложный. Я сказал, что можно стреляться, если не получается достаточно простую задачу решать достаточно простыми же методами. Каким боком тут ActiveX и что здесь делает DLL ?

>И таблицы лочить не надо.

Чисто профессиональный вопрос: откуда возникло это слово "лочить" и где надо ставить ударение ? И ЧТО ОНО ЗНАЧИТ ?
Я было подумал, что это от слова Lock (замок, запор), но оно читается как "лок", а не "лочь". Ну и попутно поясните несведущему, как вы собираетесь БЛОКИРОВАТЬ записи или даже целые таблицы в системах с большой транзакционной конкурентностью (ну это когда вероятность того, что на "одно место" будет в течение относительно небольшого периода времени сделано более одной заявки, достаточно высока) и каким образом ActiveX или тем более DLL компенсирует Вам отсутствие соответствующих реальных механизмов блокирования на сервере ? Ибо большинство серверов понятие "блокировка" понимают несколько иначе, чем Вы ;))

← →
ANB © (2006-09-29 12:31) [53]

> Отказался потому, что (это условие заказчика), перевозчик
> может без предупреждения, в последний момент заменить автобус

Каким боком это к комбобоксу ?

Значится, предлагаю следующее решение :

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

← →
MsGuns © (2006-09-29 13:32) [54]

>ANB © (29.09.06 12:31) [53]

Не канает - актива нетути и ничего не "лочится" ;)))

← →
Petr V. Abramov © (2006-09-29 13:41) [55]

я б вообще от всяческих комбиков пр. вещей, связанных с мышиной возней отказался.
Большинство людей просят БИЛЕТ, а не "билет на такое-то место" Исходя из этого: по нажатию какой-то кнопки в правой части клавиатуры блокируем место чем-нибудь типа select ... for update, печатаем билет и быстро commit.
примерно по тому же принципу действуем, если просят N билетов или N рядом.
и уж для оставшихся 1% принципиальных делаем возможность ввести "билет на 19-е место". После числа цифры "19" (т.к. нажать 2 кнопки справа клавиатуры быстрее, чем крутить комбик, да еще с в общем случае неактульными данными) либо вылезает билет, либо сообщение "занято". И уж на совсем редкий случай, когда начнут говорить "а перечислите, какие есть" делает что-то типа комбика ( ессно, без гарантии, что пока кассир будет перечислять свобобные места, они не уплывут)
таким образом еще и исключается ситуация, когда место в непонятном состоянии (и не продано, и не свободно, с большими шансами, что автобус уйдет), а кассир занят выдачей жалобной книги.
тупо, но эффективно

← →
Petr V. Abramov © (2006-09-29 13:42) [56]

я б вообще от всяческих комбиков пр. вещей, связанных с мышиной возней отказался.
Большинство людей просят БИЛЕТ, а не "билет на такое-то место" Исходя из этого: по нажатию какой-то кнопки в правой части клавиатуры блокируем место чем-нибудь типа select ... for update, печатаем билет и быстро commit.
примерно по тому же принципу действуем, если просят N билетов или N рядом.
и уж для оставшихся 1% принципиальных делаем возможность ввести "билет на 19-е место". После ввода числа "19" (т.к. нажать 2 кнопки справа клавиатуры быстрее, чем крутить комбик, да еще с в общем случае неактульными данными) либо вылезает билет, либо сообщение "занято". И уж на совсем редкий случай, когда начнут говорить "а перечислите, какие есть" делает что-то типа комбика ( ессно, без гарантии, что пока кассир будет перечислять свобобные места, они не уплывут)
таким образом еще и исключается ситуация, когда место в непонятном состоянии (и не продано, и не свободно, с большими шансами, что автобус уйдет), а кассир занят выдачей жалобной книги.
тупо, но эффективно

← →
Petr V. Abramov © (2006-09-29 13:45) [57]

сорри да дубль.
и еще - сначала коммит, потом печатаем, иначе при глюке после печати транзакция может и откатиться, и 2 билета на одно место обеспечены.

← →
ANB © (2006-09-29 13:48) [58]

> я б вообще от всяческих комбиков пр. вещей, связанных с
> мышиной возней отказался

не, это однозначно надо чтобы с клавы работало. Жмет кнопку заказа - первые свободные места автоматом могут заказываться (можно заранее вводить нужное количество мест). если бабушка начинает канючить "мне впереди или сзади", дать возможность поменять места. Но - саначала заказ, потом продажа. т.е. минимум 3 состояния свободно, заказано, продано.

← →
Petr V. Abramov © (2006-09-29 13:54) [59]

> ANB © (29.09.06 13:48) [58]
> минимум 3 состояния свободно, заказано, продано.
ОДНОЗНАЧНО! хотя бы для корректного отслеживания ситуации "билеты кончились"

← →
MsGuns © (2006-09-29 15:08) [60]

>Petr V. Abramov © (29.09.06 13:54) [59]
>> минимум 3 состояния свободно, заказано, продано.
> ОДНОЗНАЧНО! хотя бы для корректного отслеживания ситуации "билеты кончились"

Не так категорично.
Вполне имеет право на жизнь еще 2:
1. "Бронь" (Если "заказано" интерпретировать как "зарезервиро" на время полного завершения операции продажи билета) - для обеспечения личного резерва, например, начальника вокзала для непредвиденных случаев.
2. "Бронь на комплект" для резервирования мест "подряд" под групповое обслуживание (туры, экскурсии, семейные купе, каюты и т.д.)

← →
MsGuns © (2006-09-29 15:09) [61]

Запостил, а потом вспомнил:
еще одно - "возврат"

← →
Petr V. Abramov © (2006-09-29 15:38) [62]

> MsGuns © (29.09.06 15:08) [60]
> Не так категорично.
можно еще десяток придумать. но вот без первых трех - тяжеловато

← →
alabama01 (2006-10-02 04:18) [63]

> MsGuns © (29.09.06 11:54) [52]
>
> >alabama01 (29.09.06 01:41) [51]
> >Этот алгоритм только кажется сложным.
>
> Я не сказал, что он сложный. Я сказал, что можно стреляться,
> если не получается достаточно простую задачу решать достаточно
> простыми же методами. Каким боком тут ActiveX и что здесь
> делает DLL ?

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

> Чисто профессиональный вопрос: откуда возникло это слово
> "лочить" и где надо ставить ударение ? И ЧТО ОНО ЗНАЧИТ
> ?

Лочить = блокировать. Откуда возникло - сказать трудно. Скорее всего потому, что "лочить" звучит лучше, чем "локить", хотя это спорно.

> Ну и попутно поясните несведущему, как вы собираетесь БЛОКИРОВАТЬ
> записи или даже целые таблицы в системах с большой транзакционной
> конкурентностью (ну это когда вероятность того, что на "одно
> место" будет в течение относительно небольшого периода времени
> сделано более одной заявки, достаточно высока) и каким образом
> ActiveX или тем более DLL компенсирует Вам отсутствие соответствующих
> реальных механизмов блокирования на сервере ? Ибо большинство
> серверов понятие "блокировка" понимают несколько иначе,
> чем Вы ;))

Я не собираюсь их блокировать.
Вместо блокировки таблиц применяется критическая секция в длл.
Эффект тот же, однако таблицы не блокируются. Поскольку проверка на свободные места осуществляется на стороне сервера - скорость очень высокая, примерно 0,030 сек. первый раз, и 0,002 сек. последующие.

> ANB © (29.09.06 12:31) [53]
>
>
> > Отказался потому, что (это условие заказчика), перевозчик
> > может без предупреждения, в последний момент заменить
> автобус
>
> Каким боком это к комбобоксу ?

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

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

← →
sniknik © (2006-10-02 09:43) [64]

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

p.s. ну, на самом деле это твое дело, хочеш заниматься самообманом - пожалуйста, считаеш что лучше всех все понимаеш и твой вариант рабочий/решает поставленую задачу и лучший - да ради бога. но только тогда не пытайся тут чегото доказывать так как это делаеш ты, тут нужны четкие и понятные описания логики.
например описание почему без резервирования/блокировок/сообщений о занятости при "билет всегда свободен" и вдруг не может быть обрашений/продаж одного и тогоже места? только не надо глубокомысленного - "критические секции...", сами по себе они ничего не решают, а если ими сделана блокировка то чем это отличается от того что тебе предлагали? и почему нет сообшений о занятости а места всегда свободны?

← →
ANB © (2006-10-02 10:09) [65]

> Нет никаких сообщений о занятости, выбранное место всегда
> есть в наличии.

ИМХО. Зуб даю, что таки кассиры умудрятся наделать кучу дырок (и будет неудобно продавать места рядом, что вызовет недовольство пассажиров) или продать два билета на одно место.
ЗЫ. критическая секция в DLL будет работать только в рамках одного процесса.
По поводу визуальности выбора - вовсе необязательно вообще заполнять конфигурацию мест в автобусах. Можно выводить и прямоугольником. хоть 8*8. :)

← →
Petr V. Abramov © (2006-10-02 13:19) [66]

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

← →
MsGuns © (2006-10-02 13:59) [67]

"Королей мешаю я с тузами, и с дебютом путаю дуплет" (с)
Это по поводу "критических секций" в частности, и каши в голове автора - в целом

← →
alabama01 (2006-10-03 01:52) [68]

> sniknik © (02.10.06 09:43) [64]

> а ты говориш что отказался от данных тебе идей, ничего не
> "лочится"/резервируется потому что перешли на dll (???),
> звучит странно. (не то чтобы в dll нельзя сделать резервирование,
> а то что вы это обошли перейдя на них)

Нигде я такого не говорил. Наоборот, мы использовали почти все высказанные советы. И резервирование, и откат, и обновление данных для кассира, почти все, что тут обсуждалось. Еще раз повторяю, dll потребовалось вводить для того, чтобы, коротко говоря, оповестить все копии программы о произошедших изменениях в количестве свободных мест, без дополнительного уведомления кассира посредством вывода сообщений. Один что-то сделал, у других это тут же отразилось. И если у кассира почти мгновенно отображается измененная информация, то он в принципе не может выбрать занятое место, во всяком случае так было задумано. Что тут не ясно? Все остальное - как обычно. А по поводу пресловутых "критических секций" так вот что скажу: как известно, код, написанных в этих секциях одновременно может выполнить только один, так вот в этом коде и определяется количество свободных мест и, если надо, изменяется их количество и резервируется место для продажи, оповещаются другие копии программы. Действительно, это используется как аналог блокировки.
Все это работает. Никакой каши в моей голове нет, и ничего я никому не "замазываю" и самообманом не занимаюсь.
Один выявленный недостаток - это то что не видно, есть ли места зарезервированные, но не проданные. Чуть попозже прикрутим визуальное отображение, свободные одним цветом, зарезервированные другим, проданные третьим. В самом деле, как высказался ANB © (02.10.06 10:09) [65], это можно сделать схематически и не заморачиваться на реализм.

> [68] alabama01 (03.10.06 01:52)
> как известно, код, написанных в этих секциях одновременно
> может выполнить только один

У тебя все кассиры работают на одной машине с одним и тем же экземпляром приложения?

> Никакой каши в моей голове нет

Ну как же нет? Ты же не понимаешь, что такое крит.секции!

> Нигде я такого не говорил.

alabama01 (29.09.06 01:41) [51]
> Зато нет никаких дополнительных сообщений о недоступности выбранного места.
> Выбранное - всегда есть.
> И таблицы лочить не надо.

alabama01 (02.10.06 04:18) [63]
> ...
> Я не собираюсь их блокировать.
> Вместо блокировки таблиц применяется критическая секция в длл.

ага, а у меня бабушка балерина...

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

p.p.s. повторюсь, мне совершенно пофигу как вы там сделали, ваши проблемы, но судят о тебе и том что вы сделали по тому что ты показал/расказал сдесь... и показаное сдесь, логика, вовсе не такое радужное как заверения о работоспособности алгоритма.
и еще, если чтото использовал то оповести автора в ветке, этого как то приличия требуют. а не (смысл, краткое содержание ветки) "все фигня, мы пошли своим путем. сделали круче!, а когда "приперли", мы все использовали! свои только заморочки, зачем против своего же выступаете?"... некрасиво выглядит.

> код, написанных в этих секциях одновременно может выполнить
> только один,

Угу один поток этого же процесса. Так как другие процессы используют другие экземпляры этой же DLL и вполне могут работать параллельно. А каким боком на сервере это вам помогает - х.з. Уж лучше бы быренько накидали экзешник DCOM сервера. Благо делфи позволяет это сделать не заморачиваясь на тонкости технологии.

>alabama01 (03.10.06 01:52) [68]
>Еще раз повторяю, dll потребовалось вводить для того, чтобы, коротко говоря, оповестить все копии программы о произошедших изменениях в количестве свободных мест

Что значит "оповестить копии" ? Как Вы не можете понять, что с т.зр. БД абсолютно фиолетово в каком "родстве" находятся два клиента-конкурента, являются они "копиями" или не являются. И опять же неясно, причем тут длл, если эти "копии" сидят на разных компах (применительно к удаленным сетям так и врвзных городах). Или у Вас пять операторов в реале сидят за одним компом и работают с пятью экземплярами ПО ? (Хотя и в этом случае тайна - зачем тут длл ибо ничего конкретно не решает)

>Один что-то сделал, у других это тут же отразилось. И если у кассира почти мгновенно отображается измененная информация, то он в принципе не может выбрать занятое место, во всяком случае так было задумано. Что тут не ясно?

Неясно все, кроме одного - Вы совершенно не предстваляете себе МЕХАНИЗМ РАЗРУЛИВАНИЯ КОНФЛИКТОВ. Что значит "мгновенно отображается" ? Вы уверены, что в случае упомянутой мною выше гостинничной системы изменение в гостиннице Россия ТУТ ЖЕ отобразится на дисплее ВСЕХ администраторов всех других гостинниц ? А если даже отобразится, Вы уверены что это им НУЖНО ?
Еще раз повторяю, - обратитесь к людям, имеющим опыт работы с подобными системами, например, кассирам касс, операторам банков, администраторам гостинниц и т.д. Поговорите с ними и у Вас многое "прояснится на доске".
Главным образом то, что проверка на резервирование или бронирование (как угодно) должна выполняться не при ПРОСМОТРЕ "свободных" мест, а непосредственно при этом самом роезервировании или бронировании.
ИМХО, вот этот момент почуму-то никак до Вас не дойдет. Вот это-то механизм "блокировки" повторного резервирования обеспечит любой нормальный сервер безо всяких Ваших "защищенных блоков", дээлелек, активиксов и прочих "научных" терминов, коими Вы ткт так обильно сорите. С помощью примитивных триггеров хотя бы.

>А по поводу пресловутых "критических секций" так вот что скажу: как известно, код, написанных в этих секциях одновременно может выполнить только один, так вот в этом коде и определяется количество свободных мест и, если надо, изменяется их количество и резервируется место для продажи, оповещаются другие копии программы. Действительно, это используется как аналог блокировки.

Ничего не понял. А Вы ?

>Никакой каши в моей голове нет

Увы, что есть, то есть.

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

Это не недостаток. Это НОРМАЛЬНАЯ СИТУАЦИЯ. Когда отображаемая
на дисплее информация содержит устаревшие данные. Для этого собственно и служит регулярное, через определенный момент времени обновление информации. Механизм которого можно наглядно увидеть на табло любого вокзала или аэропорта. Нет ничего страшного, когда оператор пытается "выписать" билет на конкретное место, а система ему отказывает, т.к. с момента псоледнего обновления его экрана кто-то в Мухосранске или Урюпинске уже выписал билет на это место. Кстати, а я вот так и не понял, какая мне, как клиенту, разница, какой НОМЕР места мне будет выписен, например 17 или 29 ? Главное, чтобы оно было в вагоне нужного класса и нижнее. Или я чего-то недопонимаю ?

← →
saxon (2006-10-03 14:15) [73]

Как предположение: длл наверное что то типа апп-сервера или он и есть (т.е. она не на клиентах работает).

> Кстати, а я вот так и не понял, какая мне, как клиенту,
> разница, какой НОМЕР места мне будет выписен, например 17
> или 29 ? Главное, чтобы оно было в вагоне нужного класса
> и нижнее. Или я чего-то недопонимаю ?

17 - подальше от туалета, например (ночью слышно как люди туда - сюда) и вообще, что не человек то свои заморочки. :)

я делал трехзвенкой:
в выборку свободных мест добавил калк поле... поле заполняется на сервере из Memory таблицы блокировок: Место, оператор... если запись имеется возвращается id заблокировавшего если не нуль значит ЗАНЯТО, иначе свободно...
Если оператор хочет заблокировать место то вызывает соотв метод сервера - разблокировать может только сам оператор (входят в систему по id) или админ/глав кассир
блокировки в базе не зранятся, а хранятся в памяти

> [74] Slym © (04.10.06 04:50)
> в выборку свободных мест добавил калк поле... поле заполняется
> на сервере из Memory таблицы блокировок

Ты путаешь понятие калк поля с чем-то еще. Если поле возвращается с сервера, то это уже не калк в терминах Delphi, несмотря на то, что оно все-таки вычисляется, но вычисляется-то на сервере!

> блокировки в базе не зранятся, а хранятся в памяти

Изобретение велосипеда, хотя может для трехзвенки это в порядке вещей?

evvcom © (04.10.06 8:22) [75]
Ты путаешь понятие калк поля
Калк поле оно и в африке Калк поле... на сервере оно калк а на клиенте ридонли поле

← →
alabama01 (2006-10-05 01:00) [77]

> MsGuns © (03.10.06 13:25) [72]

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

Соглашение о терминах:
NTserver - сервер NT или его потомки, типа 2000 или 2003.
SQLserver, СУБД - MSSQLserver, установленный на NTserver.
Приложение-клиент, приложение, программа - программа, работающая на клиентской машине, с которой работают кассиры.
БД - база данных, с которой работает приложение-клиент.
"приложение смотрит" - приложение, работающее на клиентской машине выполняет запрос к БД, с целью получить данные для выполнения необходимых ему действий. В необходимых случаях с блокировкой соответствующих таблиц.
Обновление данных - запрос к БД, с целью получения данных, актуальных на текущий момент времени.

Предлагаемый Вами вариант понимаю примерно так:
(1) Кассир К1 резервирует для продажи место №1 на рейсе Р1, у которого количество мест равно, скажем, 10.
Реализуется, например, как запись id рейса Р1, места 1, id кассира в таблицу зарезервированных мест.
(2) Берет деньги, считает, препирается/консультирует пассажира, словом, тратит время.
(3) В промежуток времени (2) кассир К2 тоже хочет продать билет на рейс Р1.
(а) При выборе рейса Р1 приложение-клиент смотрит, (в данном случае с блокировкой), проданные + зарезервированные места, считает свободные и предлагает их для продажи кассиру К2, т.е. обновляет данные. У К2 место №1 будет отображено как зарезервированное. Остальные 9 доступны для резервирования и продажи. В этом случае - все нормально.
(б) Если же у К2 рейс Р1 уже был выбран, то место №1 у него считается доступным для продажи. Т.е. у него на экране устаревшие данные. При попытке выбрать место №1 приложение смотрит, что это место зарезервировано, выводит сообщение кассиру К2 и обновляет данные. Кассир К2 выбирает место №2 и резервирует для продажи.
(4) В это время пассажир кассира К1 передумал ехать на 1 месте, а решил на 2. У К1 это место пока отображается как свободное. При выборе места №2 место №1 удаляется из таблицы зарезервированных, а для К1 повторяется вариант из (3б).
(5) при продаже соответствующее место удаляется из зарезервированных, и прописывается в таблицу продаж, в одной транзакции.
(6) При простое, когда никто ничего не продает, приложение периодически (с каким, кстати, периодом?) обновляет данные о рейсах.
(7) и так далее.
Если я Вас неправильно понял, поправьте меня. Затем продолжим.

> [77] alabama01 (05.10.06 01:00)

6) Зачем? Обновление, ИМХО, должно быть
а - при первоначальном запросе
б - при коллизии
в - по требованию кассира

>alabama01 (05.10.06 01:00) [77]

Эк Вас задело, что Вы целый роман написали ;)

Резюме подавляющего кол-ва критических реплик в том, что НЕ НАДО НИЧЕГО ПРЕДПРИНИМАТЬ ВО ИЗБЕЖАНИЕ КОНФЛИКТОВ НА КЛИЕНТЕ ИБО ВСЕ РЕАЛИЗУЕТСЯ ДОСТАТОЧНО ПРОЗРАЧНО И НАДЕЖНО НА СЕРВЕРЕ.
При этом не уточняется какой сервер. В принципе - любой, в т.ч. и локальные СУБД. Главное - это централизация кода распределяющего непосредственно в БД "места"

Описанный Вами в [77] "конфликт" почти на 100% совпадает семантически с "классическим" примером транзакций, приводимых в куче книг по БД (имеется в виду банковская операция по переводу денег с одного расчетного счета на бругой).
Вот почему я и советовал Вам прежде чем углубляться в тонкости реализации (защищенные блоки, динамические библиотеки, COM-интерфейсы и т.д.) ознакомиться более внимательно с означенной проблемой и путями ее решения.

Продажа билетов несколькими кассирами Найти похожие ветки