Вы бы использовали АОП для управления транзакциями базы данных?

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

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

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

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


java spring database transactions aop
person oxbow_lakes    schedule 08.03.2009    source источник

Ответы (3)


arrow_upward
4
arrow_downward

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

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

person javashlook    schedule 08.03.2009
comment
+1 - это хороший совет использовать аннотации в Spring 2.5. - person duffymo; 09.03.2009
comment
Причина, по которой я изначально этого не делал, заключается в том, что обычно бизнес-логика должна быть транзакционной, а не отдельными вызовами постоянства. Я не хотел, чтобы Spring импортировался повсюду — я хотел, чтобы детали реализации постоянства были максимально изолированы. - person oxbow_lakes; 09.03.2009
comment
Верно, именно поэтому аннотации @Transactional принадлежат сервисному уровню, а не уровню постоянства. Транзакции относятся к единицам работы в вариантах использования, которые представлены услугами. - person duffymo; 09.03.2009
comment
Да, но сервисный уровень может состоять из десятков интерфейсов. Я не хотел вводить зависимости от Spring для всего этого. Я думаю, что я смягчаюсь к этому сейчас, хотя - person oxbow_lakes; 09.03.2009
comment
Я всегда помещаю @Transactional в реализации интерфейса (сервиса), а не в сами интерфейсы. И эти реализации даже упакованы отдельно. Таким образом, некоторые интерфейсы, такие как UserManager, импортируют только объекты домена/бизнеса, в то время как UserManagerImpl имеет зависимости Spring и Hibernate. - person javashlook; 09.03.2009
comment
javashlook верен, аннотации @Transactional относятся к реализации, а не к интерфейсу. - person duffymo; 09.03.2009

arrow_upward
2
arrow_downward

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

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

person Antonio    schedule 09.03.2009

arrow_upward
0
arrow_downward

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

person Nick    schedule 09.03.2009
comment
База данных все еще делает это. Как вы управляете двухэтапной фиксацией при таком расположении? Должна быть третья сторона, которая знает всех игроков, и это менеджер транзакций среднего уровня. - person duffymo; 09.03.2009
comment
Точно - единственный способ сделать это правильно - переместить бизнес-логику внутрь базы данных. Например, insert-transaction/update-account должны быть соединены вместе, иначе вы столкнетесь с проблемами атомарности. - person oxbow_lakes; 09.03.2009
comment
Вы ничего не упомянули о двухфазном коммите. Вы просто сказали управление транзакциями базы данных, что намного проще, чем двухэтапная фиксация. Если вам нужно 2PC, Spring @Transactional вам тоже не поможет. - person Nick; 09.03.2009