hvladЭто было бы смешно, если бы не было так нудно...Один раз что-то подобное всё-таки получилось . Да, там другая задача, но принцип тот же - через контексты. Правда, еще и db-level триггер нужен :-)
Как будет время - попробую сделать что-то на тему "неотрицательных остатков", как знать - вдруг попрёт...

Ivan_Pisarevskyвнес клиент запись в свою корзинку, надо ее закоммитить и на регистр остатков можно навесить типа софт резерв.Кто будет снимать этот soft-reserve в случае выпадения юзера, его создавшего, в долгую нирвану ? Доверять проверку на неактивность экземпляру приложения, который у него запущен, - нельзя (оно вообще может зависнуть или отвалиться от сети и проч).
Запускать по крону задание - это ставить приложение в зависимость от внешней среды (как минимум - от факта, что служба планировщика действительно работает, а также что само задание в ней не "почикали" случайно). Не очень гут, КМК...
ЗЫ. Кроме того, когда задание на грохание мягких резервов отработает и удалит к-л резерв, приложение должно непременно отреагировать на сиё, предупредить юзера. А это значит - отдельный поток с периодическим контролем записей, которые добавлялись юзером в корзину, с проверкой: "как там, вас не грохнули еще ?"