Здравствуйте, Ballista, Вы писали:

B>nested транзакция — согласен, мутная штука. но почему у нас разговор всплыл о nested, если REQUIRES_NEW должна была создать "completely independent transaction". получается, что не смотря на заявление в документации, реально эта "completely independent transaction" все равно подвид nested транзакции на уровне JPA и лишь на уровне JDBC отдельная коннекция/транзакция.

Возможно. Вообще пока есть и другой вариант. Кто у вас вызывает forceTableUpdate? И какая стратегия для добавления транзакций используется: proxy или манипуляция байткода? Ни в одном не будут работать вызовы this.forceTableUpdate(). При прокси не будут работать и вызовы через класс а не через интерфейс. При использовании модификации байткода вызовы через класс должны работать (при условии, что класс инжектится а не явно создается). Примеры на ORM содержат и REQUIRES_NEW, так что, возможно, оно все-таки поддерживается.

Ну а по вопросу. У entity manager же свои транзакции, в рамках которой он отслеживает изменения объектов. И вот с ним все равно можно смешивать объекты из внешней и внутренней (пусть и независимых) транзакций. Это в jdbc template такое вряд ли получится (ну хотя я могу предложить в процессе разбора result set вызывать какой-нибудь метод с requires_new транзакцией). Например, объект, созданный во "внутренней" транзакции может получить ссылку на объект, полученный во "внешней" транзакции.

Но я пока не уверен на 100%, что entity manager виноват. Для начала убедитесь, что простые JDBC-транзакции работают. Сделайте два jdbc template с каким нибудь простым запросом. Один — во внешней транзакции, другой — во внутренней. И поиграйтесь с запросами/исключениями. Если они действительно независимы (как транзакции), значит проблема в жизненном цикле entity manager. Иначе у вас не срабатывают аннотации транзакционности и нужно бороться сначала с этим.