AOP, Spring и область видимости транзакций

Вам не нужна единая точка входа, но вам нужна возможность применить транзакционный перехватчик ко всем точкам входа, чтобы повторно входящие вызовы могли участвовать в одной транзакции. Предполагая, что вы можете это сделать, вы могли бы сделать это с помощью флага ThreadLocal и специальной реализации org.springframework.transaction.support.TransactionSynchronization.

Вы бы изменили Z.T, чтобы установить флаг ThreadLocal, когда продолжение фиксации безопасно. В вашей реализации TransactionSynchronization.beforeCommit(), которая вызывается из PlatformTransactionManager, вы можете проверить флаг и использовать его, чтобы определить, разрешить ли выполнение фиксации. Вы можете принудительно выполнить откат, бросив RuntimeException, если флаг отсутствует.

Одно предостережение заключается в том, что если у вас есть другие типы транзакций (которые не включают три описанных вами координирующих класса), вам необходимо убедиться, что они не откатываются случайно. Для этого вы можете пометить эту «специальную транзакцию» в A.Foo, B.Bar и Z.T с помощью другого флага ThreadLocal, а затем проверить этот флаг в предложении защиты в методе beforeCommit(), упомянутом выше. Псевдокод:

void beforeCommit() {
  if in special transaction
    if commit flag not set
       throw new RuntimeException("cancel transaction")
    end if
  end if
end

И, очевидно, это взлом, и я бы не стал защищать систему с нуля :).

Идиома Spring рекомендует иметь интерфейс службы, который знает о единицах работы, и интерфейс постоянства, который имеет дело с реляционными базами данных. Методы в интерфейсе службы должны соответствовать вашим вариантам использования. Реализация службы знает обо всех моделях и пакетах персистентности и классах, необходимых для достижения целей варианта использования.

«Экземпляры могут вызывать друг друга, и, как уже упоминалось, не существует общей точки входа, вызывающей все экземпляры из одной точки входа (например, уровня обслуживания), которая могла бы стать легкой мишенью для транзакционного тега spring».

Это предложение говорит мне, что вы делаете что-то таким образом, который не так легко поддается идиоме Spring. Трудно сказать точно, что вы хотите, но похоже, что вы отбрасываете два наиболее важных слоя, которые рекомендует Spring. Если вам сложно идти против течения, возможно, это ваш дизайн, который требует доработки.

«... разные вызывающие абоненты с другими классами между ними ...» - возможно, вам нужно объявить транзакции индивидуально для этих вызывающих абонентов.

Вы можете объявлять транзакции в конфигурации XML, используя аспекты, либо с помощью Spring AOP, либо AspectJ. Spring 2.5 и выше теперь дает вам возможность использовать аннотации, если вы предпочитаете их конфигурации XML.

Ваше описание меня ужасно сбивает с толку. Может быть, это одна из причин, по которой у вас тоже с этим проблемы. Я бы переосмыслил или уточнить.

С весенними транзакциями и aop вы можете это сделать, но это будет немного "взломать" ...

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

Теперь единственный способ сказать Spring об откате транзакции - это выбросить исключение через границу транзакции. Таким образом, что вам нужно сделать, если вы войдете в эту область Z, которая вызовет фиксацию, тогда вам нужно будет поместить что-то в локальный поток (также, возможно, через аспект), который этот "внутренний" аспект найдет и, таким образом, не выбросит исключение для отката транзакции. Если вы не введете Z, то локальный поток не получит флаг, и когда вы вернетесь через внутренний аспект, будет выброшено исключение для отката транзакции. Вам, вероятно, придется проглотить это исключение.