Будете ли вы использовать AOP для управления транзакциями базы данных? - PullRequest
3 голосов
/ 09 марта 2009

Некоторое время назад я написал приложение, которое использовало Spring AOP для определения того, какие методы были транзакционными. Теперь у меня возникают мысли о том, насколько это была отличная идея; Меня несколько раз ударили после незначительного рефакторинга (изменение сигнатур методов и т. Д.), Который, конечно, не проявляется, пока что-то не получится (и у меня нет логически несовместимой базы данных).

Так что меня интересует несколько вещей:

  1. Решили ли другие люди вернуться к явному управлению транзакциями (например, с помощью @Transactional аннотаций)?
  2. Существуют ли полезные инструменты, которые я могу использовать в процессе сборки, чтобы определить, было ли что-то "сломано"?
  3. Если люди используют AOP для управления транзакциями, какие шаги они предпринимают, чтобы избежать ошибок, которые я совершил?

Я использую IntelliJ IDEA, который позволяет вам просматривать декорированные методы и будет реорганизовывать конфигурацию Spring XML вместе с изменениями имени метода, но этого не всегда достаточно (добавление параметра в метод в неправильном месте может повлиять на например, аспект срабатывает)

Ответы [ 3 ]

4 голосов
/ 09 марта 2009

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

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

2 голосов
/ 09 марта 2009

Относительно (1): Я нашел @Transactonal более практичным решением для всех проектов, над которыми работали в последние несколько лет. Однако в некоторых очень специфических случаях мне также пришлось использовать Spring AOP, чтобы разрешить использование более одного соединения JDBC / TransactionManager, поскольку @Transaction привязан к одному диспетчеру транзакций.

Относительно (2): Сказав это, в смешанном сценарии я делаю много автоматизированного тестирования, чтобы найти, возможно, неработающий код. Я использую SpringT AbstractTransactionalJUnit4SpringContextTests / AbstractTransactionalTestNGSpringContextTests для создания моих тестов. Пока это очень эффективное решение.

0 голосов
/ 09 марта 2009

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

...