тогда в минус ничего не уйдёт

Да или лок

Но etki не хочет лок, а хочет rr

А почему не делать:

update products
set count=count-1
where count > 0
and id = ?

Вся история с уровнями изоляции в том, что финальная история транзакций должна иметь возможность быть приведенной к 1 .. N линейных историй, как если бы транзакции применялись по одной.
Уровни изоляции позволяют феномены, те или иные нарушения, с которыми такие истории могут быть построены.
RR не позволяет феномен изменяющейся записи.
Таким образом недопустима ситуация, когда к концу транзакции запись изменил кто-то другой.
Никаких локов, сериалайзаблов и прочего не нужно в помине.

И потом проверять число обновленных строк? Ну как вариант

Да

Там есть critique of ansi sql, очень хорошо прочищает голову по поводу того что это и зачем.

При rr ты не увидишь изменения от параллельных транзакций. А приведение к линейной истории - это и есть serializable

Более того, lock-based субд, mysql в том числе, будут сами брать лок на запись и недоуменно смотреть чем это вы там занимаетесь

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

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

Вот такое получилось

бля, ток надо не логикал энд а логикал ор ебашит

Теперь его еще залупить, как посоветовали здесь
Через фор норм будет сделать?

и при успешном выполнении это:

em.persist(order);
 transaction.commit();

а с постгресом все равно придется ловить и обрабатывать исключения

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

У меня слов просто нет. То что у него под капотом другой движок не означает что он пропускает феномен и rr для него имеет какие-то исключения по сравнению с субд у которой под капотом локи.