Блог

Есть ли какие-либо веские причины, по которым в их коде не было бы управления транзакциями?

Вопрос возник при разговоре с администратором базы данных, который очень нервничает, когда я вызываю spring / hibernate. Я упоминаю, что Spring может обрабатывать транзакции, используемые с таблицами сопоставления Hibernate с объектами и т.д., И возникает проблема, что база данных (Oracle10g) уже обрабатывает управление транзакциями, поэтому мы должны просто использовать это. Он даже предложил идею о том, что мы создаем набор процедур БД для выполнения вставок / обновлений, чтобы база данных могла обрабатывать данные более эффективно, возвращая 0/1 о том, сработала ли вставка / обновление.

Есть ли какие-либо веские причины, по которым ваше приложение не должно обрабатывать какие-либо транзакции? Мой администратор базы данных невежественен? Я думаю, что да, но я не очень хороший оратор, когда не уверен в ответе… вот почему я ищу ответ.

Я думаю, что здесь какое-то недоразумение.

Дело в том, что база данных не управляет транзакциями в том же смысле, что Spring / Hibernate.

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

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

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

Существует также аргумент (применительно к сценариям транзакций), что это быстрее, потому что меньше обходов, у вас есть один вызов хранимой процедуры, которая выполняет все и возвращает результат, в отличие от вашего обычного приложения Spring / Hibernate, где у вас есть несколько запросов или обновлений, и каждое утверждение передается по сети в базу данных (хотя Hibernate кэширует и переупорядочивает, чтобы попытаться свести это к минимуму). Минимизация сетевых обходов, вероятно, является наиболее веской причиной для такого подхода, вы должны взвесить, стоит ли жертвовать гибкостью ради сокращения сетевого трафика, или это преждевременная оптимизация.

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

Итак, резюмируя, вот аргументы в пользу сценариев транзакций:

• Меньше сетевого трафика

• Дешевые разработчики

• полный контроль администратора базы данных (с вашей точки зрения, он будет полным узким местом)

Как упоминалось выше, нет способа «использовать транзакции» с точки зрения базы данных, не поставив ваше приложение в известность об этом на некотором уровне. Хотя, если вы используете Spring, вы можете сделать это довольно безболезненно, используя <tx:annotation-driven> и применяя @Transactional аннотации к соответствующим методам в классах реализации сервиса.

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