Честно говоря не очень понял вопрос - при чем тут уровни изоляции и update ? Update изначально блокирует обновляемую строку, так что если кто то изменяет кол-во товара, то срабатывает триггер, который апдейтит таблицу остатков, соответствующе в таблице остатков блокируются обновляемые записи, которые разблокируются только после выполнения в сессии COMMIT. Соответствующе пока они блокированы, другие сессии при попытке их обновления в зависимости от настроек замрут на указанный тайм-аут или же возбудят ошибку о невозможности обновления блокированных данных. Это будет так же верным и для читателей с уровнем изоляции READ COMMITED, так что и в возвращаемых в те же отчеты данные будут чистыми.

P.S. Насколько я вижу в триггере стоит ON EACH ROW. Наверное с моей точки зрения было бы эффективнее сделать AFTER TRIGGER ON EACH STATEMENT и для обновления остатков написать:
Тогда при обновлении например 100 товаров в Вашем случае будет выполнено 100 операторов update, а в моем случае все равно только один :)

авторЗначит, пока commit не скажу, любые посягательства на update таблицы промежуточных остатков будут отклонены?
Ну не любые, а именно посягательства на заблокированные в другой транзакцией записи. Если будут обновлятся совсем другие товары, то и пусть себе остатки обновляются, раз никому не мешает и ничему не противоречит :)

P.S. Правда тут требуется уточнение, что это полностью соотвествует только для ASA 9, где все блокировки идут на уровне позаписных. В предыдущих версиях ASA вполне возможна ситуация, что блокировка остатков одних товаров могла повлечь за собой блокировку целых страниц, а значит и прихватить с собой другие товары. В плане блокировок мне ASA 9 очень нравиться - блокирует ровно столько, сколько надо, экскалация блокировок происходит до уровня страниц и таблицы только в действительно нужные моменты, для особо критичных случаев остался оператор LOCK TABLE, позволяющий заблокировать всю таблицу, иногда такое при тяжелых транзакциях бывает эффективнее :) Ну чем не жизнь, а то начитаешься понимаешь в форуме MSSQL про блокировки и иногда аж дурно делается, как там все запущено - тут делай первичный кластерный, тут не делай, а тут и экскалация с чего то заблокировала всю таблицу, хотя вроде и не должна :)

Перекоса данных в блокировочниках не может быть по определению. В версионниках кстати тоже, но другая архитектура работы приводит к другим проблемам. В Сравнении СУБД копья на эту тему ораклисты и сиквельники ломают уже порядочно времени :)