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

В таблице лежат остатки товаров, которые подвергаются продаже... На кассах в момент продажи создается документ ЧЕК, в который накидываются позиции товаров исходя из текущих остатков, то есть непосредственного наличия. При добавлении позиции указывается требуемое покупателем количество. По логике вещей акт продажи должен представлять собой единую транзакцию.[/quot]
Вы не корректно, на мой взгляд, трактуете понятие "транзакция". Когда "накидывает" - это одни транзакции, которые увеличивают количество забронированное, и, соответственно, уменьшают количество свободное. А завершающая транзакция (формирования чека) уменьшает количество и, естественно, забронированное количество.
[quot [Архитектор Мендисабаль]] Суть проблемы в том чтобы одну и ту же позицию в остатках могли использовать несколько продавцов, но при этом остатки не должны уйти в минуса, или в общем говоря расходиться с реальным наличием. Поскольку незавершенная транзакция не позволяет увидеть другой транзакции сколько реально осталось в остатках с учетом резерва этой самой незавершенной транзакции, то тут и возникает вопрос: как лучше построить межтранзакционное взаимодействие, чтобы найти золотую середину между масштабируемостью и постоянной консистенцией данных.

Буду благодарен за любые идеи
[/quot]
Нет никакой проблемы))

Nafтранзакция на запись должна быть короткой и в самом конце - при закрытии чека:

1. открыли транзакцию
2. проверили наличие на остатках
3. записали изменения в БД
4. подали команду на ККМ о закрытии чека (если требуется)
5. закрыли транзакцию

транзакция должна блокировать данные
))) в самом конце сообщить, что зря старался...

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

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

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

Злой Бобр[Архитектор Мендисабаль],

Вам дали правильный ответ в первом же посте - нельзя ограничивать кассу количеством товара. Дело кассира пробить по кассе ровно столько товара, сколько взял покупатель. И кассиру абсолютно до лампочки сколько там висит на остатке. Поэтому никаких проблем нет. У вас есть таблица с перечнем товаров и ценой - ее и используйте в процедуре продажи по кассе. И поскольку вы туда обращаетесь только для чтения то транзакция будет только на таблице продаж по кассе а не на товаре. Соответственно делайте транзакцию минимальной и все у вас получится.
Тогда бы и вопроса не было бы. Так что ответ (подразумевающий наличие товара в руках покупателя) - не правильный)).
"На кассах в момент продажи создается документ ЧЕК, в который накидываются позиции товаров исходя из текущих остатков, то есть непосредственного наличия."
Впрочем, уже выяснилось, что автора вопроса никакие ответы не интересуют))