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

В таблице лежат остатки товаров, которые подвергаются продаже... На кассах в момент продажи создается документ ЧЕК, в который накидываются позиции товаров исходя из текущих остатков, то есть непосредственного наличия. При добавлении позиции указывается требуемое покупателем количество. По логике вещей акт продажи должен представлять собой единую транзакцию.
[/quot]

Обычно кассы работают off-line, т.е. отдельно от основной БД, или хотя бы могут так работать.
И обычно остатки списывают в конце кассовой смены. При этом только проведение одного чека должно быть транзакцией.
А два соседних чека делать транзакцией вовсе не обязательно.

[quot [Архитектор Мендисабаль]]
Суть проблемы в том чтобы одну и ту же позицию в остатках могли использовать несколько продавцов, но при этом остатки не должны уйти в минуса, или в общем говоря расходиться с реальным наличием.
[/quot]

Не, суть ты кажется неверно понимаешь. Суть в том, что ты НЕ ЗНАЕШЬ сколько у тебя товара реально. У тебя есть только оценка,
близкая больше или меньше к реальности. И есть неоспоримый факт -- если ты какой-то товар продаешь, то он у тебя есть, т.е был на начало дня, не зависимо от того, сощитали ли этот конкретный экземпляр или нет. И если это неучтёнка, то по факту продажи
ты должен увеличить остатки (не обязательно исходные и даже лучше не исходные, чтобы было видно) с помощью акта пересортицы, который должен оформляться по фактической продаже.

Так что уход остатка в минус -- это нормальное явление.

[quot [Архитектор Мендисабаль]]
Поскольку незавершенная транзакция не позволяет увидеть другой транзакции сколько реально осталось в остатках с учетом резерва этой самой незавершенной транзакции, то тут и возникает вопрос: как лучше построить межтранзакционное взаимодействие, чтобы найти золотую середину между масштабируемостью и постоянной консистенцией данных.
[/quot]

Ну, там в общем всё просто, делаешь транзакцию, с UPDATE-ом, они сериализуются в очереди к остатку одного товара и всё ОК.
Причём для этого не нужно ничего делать, оно всё сделается само, автоматом, нужно только правильно оформить код.
Открыл транзакцию, сделал всё что нужно (провёл все позиции чека) -- и закоммитил, елси проблемы -- откатил.
Но к уходу остатка в минус это не имеет никакого отношения.

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


Вот блин кассиру будто делать больше нечего!
Во классно придумал!

[quot [Архитектор Мендисабаль]]Смотрите, дело даже не в минусах как таковых, а о расхождении остатков в виде цыфры в базе и конкретного колва на полке изза
[/quot]

Это всегда возможно в учёте. Это нормальное явление, его не нужно боятся.
Конечно, учёт стремиться отражать реальную картинку склада, но не всегда это получается.

[quot [Архитектор Мендисабаль]]апример такой транзакционной проблемы как потеряные изменения.
[/quot]

lost update ? Это -- проблемы СУБД, если у тебя в коде всё правильно, её не будет.
В оракле конкретно её нет. Уровень изоляции -- по умолчанию.


[quot [Архитектор Мендисабаль]]
Блокировать запись не годится потому что если ктото начал свои покупки с трусов, то второму пришедшему ТОЛЬКО за этими трусами невдомек ждать пока первый назаказывает себе еще 100 других позиций. Как собственно и организовать резерв или чтонить в этом роде меня и интересовало, потому де изменения сделанные одной транзакцией еще не видны другой пока первая не решит уже чтото...
[/quot]

Ничего блокировать не нужно, тебе нужно только правильно транзакцию организовать.
Начать, всё сделать, и завершить.

[quot [Архитектор Мендисабаль]]
Вообще я задавал этот вопрос на ветке Оракла потому что и ожидал решений с помощью доступных оракловых механизмов.[/quot]

там все механизмы --
begin tran
XXXX
commit;

и всё. При чём это универсально почти по всем СУБД.

(в оракле нет begin tran на сервере, просто делаешь первый оператор -- она сама начнётся).

LSVMasterZivпропущено...
Вот блин кассиру будто делать больше нечего!
Во классно придумал!А что, по сабжу есть другие варианты ? Кассир просто сообщает администратору о проблеме. Либо действует по инструкции.
В системе следует предусмотреть все варианты.

кассир считает деньги, а не товар.
Товар считает завскладом. По закрытии кассы это происходит.

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

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

Стал перечитывать тему с нуля...

Бредятина[Архитектор Мендисабаль],
И поймите, что дело вовсе не в "логике функционала", а в схеме БД)))

Схема БД тут ни при чём, транзакцию можно по любой схеме провести.
Максимум что будет плохого -- очень высокий уровень изоляции.

Ребята, как выглядит касса ?

1) там остатки товаров не хранятся. Вообще.
2) там хранится словарь товаров (товарной номенклатуры), со штрихкодами. И прайс-лист на них (цены)
3) отрывается кассовая смена. кассиру сдают деньги со старой смены, остаток после выемки из кассы (ему нужно на сдачу).
4) идёт торговля.
5) открывается чек, по чеку проходит несколько товаров, у каждого -- кол-во, цена, сумма позиции товарной.
Да, и ещё важное теперь -- ещё есть скидка на каждый товар. Она может пересчитываться задним числом по закрытиии чека.
6) вот если какого-то товара нет в списке товаров кассы, или на него нет штрих-кода -- вот тогда жопа, надо ждать, пока товар не найдут или покупатель от него не откажется.
7) в процессе формирования чека кассир может свободно удалять и добавлять позиции чека (если напр. покупатель откажется от чего-то).
8) чек закрывается, формируется сумма чека, как сумма позиций. Тут можно предьявить скидочную карту, тогда позициии чека могут быть пересчитаны. Из суммы чека, суммы прихода от покупателя и сдачи формируется приход в кассу от чека. В кассе в рамках кассовой смены ведётся текущий балланс кассы, он корректируется.

9) всё, чек закрыт, товар не может быть вернут (только отдельной операцией возврата, и её часто делают не в этой кассе).
10) потом всё крутится по кругу в цикле от п.5 до п.8

10) закрывается кассовая смена. Берётся балланс кассы, производится выемка денег, формируется остаток кассы на следующую смену. (выемка может производится и в процессе смены, тогда считают купюры или монеты, и балланс кассы минусуют на эту сумму).


11) в этот же момент формируется расходный лист на склад со списком проданных товаров, по сути это -- сумма всех прозиций всех чеков. Не очень важно, как их проводить в складской БД, но главное, что до этого момента касса никак не взаимодействует с БД склада, по нескольким причинам:
-- некоторые кассы просто тупо не умеют.
-- это и вредно, потому что БД склада не обязана работать всё время кассовой смены -- она может и упасть, и свет могут вырубить, и вообще. А торговать надо.

Вот тут, в пункте 11, и проводится изменение товарных остатков, это делается НЕ в кассе, и одной транзакцией (почеково или вся смена целиком или ещё как). И никаких проблем с изменением остатков нет.

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

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

Кот МатроскинMasterZivпропущено...


кассир считает деньги, а не товар.
Товар считает завскладом. По закрытии кассы это происходит.


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

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

Только вряд ли этот товарищь называется "кассир", он продавец-кассир как минимум.
" реагировать, если товар кончается " продавец, очевидно, не может -- ему же продавать надо, а не за товаром бегать.
"клиента, который заплатил но не смог получить товар,ни разу не удовлетворят мантры "Товар считает завскладом. " -- тут тоже нестрашно, ему вернут деньги, и всё. Именно поэтому существует такой документ, как чек, и процедура гашения чека.