Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Продажа билетов несколькими кассирами [D7, MSSQL]


Страницы:   1 2 3 4

alabama01 ©   (2006-09-26 07:09:00) 

Здравствуйте.
Есть программа для продажи билетов в транспортные средства, с соответсвующей БД. При продаже билета на форме кассира обновляется combobox со списком свободных мест и автоматически подставляется  первое свободное место. (сделано для скорости). При работе нескольких кассиров, у них у всех происходит то же самое. Поэтому приходится проверять не продал ли кто билет на это место, а если продал, то выводить предупреждение, чтобы выбирали другое место. Это очень неудобно. Обновление combobox'ов у всехкассиров происходит при оформлении чека любымиз кассиров Вопрос: как лучше организовать раздачу свободных мест при продаже на один и тот же рейс несколькими кассирами без малейшей возможности продажи двух и более билетов на одно место?


MsGuns   (2006-10-05 10:31:00) [1]

>alabama01   (05.10.06 01:00) [77]

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

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

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


Sergey13   (2006-10-05 08:25:00) [2]

> [77] alabama01   (05.10.06 01:00)

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


alabama01   (2006-10-05 01:00:00) [3]


> 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) и так далее.
Если я Вас неправильно понял, поправьте меня. Затем продолжим.


Slym   (2006-10-04 10:03:00) [4]

evvcom ©   (04.10.06 8:22) [75]
Ты путаешь понятие калк поля

Калк поле оно и в африке Калк поле... на сервере оно калк а на клиенте ридонли поле


evvcom   (2006-10-04 08:22:00) [5]

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

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

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

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


Slym   (2006-10-04 04:50:00) [6]

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


saxon   (2006-10-03 14:15:00) [7]

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


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

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


MsGuns   (2006-10-03 13:25:00) [8]

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

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

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

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

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

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

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

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

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

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


ANB   (2006-10-03 10:56:00) [9]


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

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


sniknik   (2006-10-03 10:07:00) [10]

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

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

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

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

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

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


evvcom   (2006-10-03 09:52:00) [11]

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

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

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

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


alabama01   (2006-10-03 01:52:00) [12]


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


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

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


MsGuns   (2006-10-02 13:59:00) [13]

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


Petr V. Abramov   (2006-10-02 13:19:00) [14]

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


ANB   (2006-10-02 10:09:00) [15]


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

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


sniknik   (2006-10-02 09:43:00) [16]

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

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


alabama01   (2006-10-02 04:18:00) [17]


> 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 сек. на выбор и распечатку чека фискальным регистратором, который и является  билетом. Повторный билет - один клик мышкой. Нет никаких сообщений о занятости, выбранное место всегда есть в наличии. У всех кассиров обновляется информация о наличии свободных мест при выборе места для продажи любым из кассиров. Визуально это выглядит как обновление одного числа, количества свободных мест,  в списке рейсов. Откат резервирования по таймеру.


Petr V. Abramov   (2006-09-29 15:38:00) [18]

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


MsGuns   (2006-09-29 15:09:00) [19]

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


MsGuns   (2006-09-29 15:08:00) [20]

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

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


Страницы:   1 2 3 4

Наверх

Титульная страница Поиск, карта сайта Написать письмо