Есть клиентский компьютер. С одной стороны он общается с SQL сервером, с другой - с фискальным принтером.

О принтере достаточно знать, что он принимает данные, печатает билет, пишет его себе в фискальную память и возвращает "ОК", если все получилось, либо всякие "ERR" в противном случае.

SQL-сервер ведет учет проданных билетов.

Требуется: при сбоях в любой момент времени (потеря связи с сервером, потеря связи с кассовым аппаратом, падение клиенского компьютера) обеспечить согласованность содержимого базы SQL-сервера и фискальной памяти принтера.

Например, ситуация:

- начали транзакцию,
- послали данные в принтер,
- он напечатал билет и сохранил в фискальную память,
- вернул OK
- клиентский комп повис, не успев сказать COMMIT
- SQL сервер, потеряв из виду клиента и не услышав COMMIT, откатил его транзакцию
- имеем: билет в фискальной памяти есть, а в БД нет.

Кто как выкручивается?

MasterZiv
Вообще чисто формально для этого нужны распределённые транзакции.


Конечно, было бы здорово, если бы из фискального принтера торчал хвост небольшого SQL-сервера, чтобы привязать его к хвосту большого, и пусть договариваются и гарантируют. А клиент чисто командует. Как сказал поэт:


Но, к сожалению, эти распределенные транзакции с принтером придется городить самому. Вот и интересно - неужели все и везде это делают, и если делают, то как именно?

LSVВы описываете онлайновую кассу, что временами очень нехорошо.
Если по правильному, то кассе должна быть офф-лайновой(т.е. с локальным сервером) с механизмом обновления/репликации с центральным сервером.

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

Получается что-то такое (кусок обсуждения). Просьба прокомментировать.

------------------

...Дело в том, что непонятно, какой момент (сигнал) считать гарантией напечатанности (или наоборот, ненапечатанности) билета. Нет такого сигнала. Вот, например, тонкий момент:

A. Посылаем на аппарат последнюю команду FISC
B. Он печатает строку "ФИСКАЛЬНЫЙ ЧЕК", заносит данные в фискальную память.
C. Возвращает OK.

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

А нам (клиентскому компьютеру) что делать, послав на A.FISC и не получив на C.OK ? Подтверждать транзакцию, записывать в базу данных проданный билет? Нельзя, потому что после команды FISC аппарат мог, например, повиснуть, выдернуться из розетки, и не выполнить шага B. Не записывать, откатывать? Но тогда получим расхождение - шаг B, возможно, выполнен, и билет, возможно, напечатан, продан и записан в фискальную память.

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

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

Последовательность действий печати билета при отсутствии ошибок такая:

1. Перед печатью билета запросить у аппарата номер последнего напечатанного билета.
2. Заносим в БД запись о билете, с его новым номером (последний напечатанный + 1), как о проданном, но пока что с флагом "Начата печать".
3. Отправляем в кассовый аппарат все команды.
4. Если получено последнее OK, снимаем у билета флаг "Начата печать". Теперь он считается проданным.

Таким образом, если прервется связь, в базе останется билет с флагом "Начата печать". Флаг означает, что его судьба неизвестна, и ее надо выяснять. Для этого, между шагами 1 и 2 всегда выполняем шаги:

1.1. Проверить в БД наличие записи с флагом "Начата печать". Если нет - к шагу 2.
1.2. Сверяем номер этого билета с полученным на шаге 1 от кассы последним напечатанным билетом.
1.3. Если последний напечатанный в аппарате равен сохраненному в базе, значит, билет был успешно напечатан. Молча снимаем флаг "Начата печать". Теперь билет считается полноценно проданным и учтенным, как в БД, так и в фискальной памяти аппарата. Переход к шагу 2.
1.4. Если же последний напечатанный в аппарате меньше сохраненного в базе, значит, он не был напечатан, и его нет в фискальной памяти. Тут нужно спросить у оператора примерно следующее:

"Предыдущий билет <реквизиты билета> не был напечатан, и не учтен в кассовом аппарате. Напечатать? Отказаться?"

Если Напечатать -

1.5. Отправляем в кассовый аппарат все команды ЭТОГО билета.
1.6. Если получено последнее OK, снимаем у этого билета флаг "Начата печать". Теперь он считается проданным. Переход к шагу 2.

Если Отказаться -

1.7. Удаляем запись из БД.

--------------------------------------

Билеты с флагом "Начата печать" не должны учитыватся в финансовых отчетах. Вообще, перед закрытием дня, когда все кассы уже заведомо закрыты (в смысле окошки закрыты, пассажиров нет), нужно делать на каждом рабочем месте "Проверку на недопечатанный билет" по тому же принципу 1 - 1.1. - 1.4. Только, в 1.4, наверное, можно не спрашивать оператора про перепечатку, а молча выполнять выбор "Отказаться" и 1.7 - то есть, если билет не учтен в аппарате, то и в базе ему делать нечего.

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

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

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

Нет, в этом случае не так. Если уж билет попал в руки пассажиру, тут не откатывать, а докатывать надо.

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

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

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