Почему JPA/Hibernate разработали способ переопределения границ транзакций даже для одного оператора вставки / обновления БД?
Везде написано, что сервисный (или любой другой) метод должен быть транзакционным для JPA Persistence Context, который будет создан, но я нигде не могу найти, что является мотивацией такого дизайна.
Скажем, я хочу вставить одну строку в БД, это всего лишь один оператор БД, который в любом случае будет транзакционным, если autocommit включен. Но внезапно, если вы используете JPA/Hibernate, тогда вы должны сделать свой бизнес-метод @Transactional для JPA, чтобы иметь возможность создавать контекст постоянства и выполнять этот единственный оператор.
В мире без JPA у нас может быть нетранзакционный метод обслуживания, содержащий даже несколько операторов БД, конечно, рискуя потерять атомарность всей операции (это, безусловно, наш выбор), так почему JPA спроектирован таким образом вынуждая нас создавать транзакционные методы, даже если этот метод содержит один оператор БД и в любом случае этот оператор будет выполняться в транзакции с autocommit=true?
4 ответа
Я считаю, что все, что связано с СУБД, будет транзакционным, даже если это атомарная операция или случай не JPA. Говоря о потере данных, все зависит только от настроенного уровня изоляции. Даже если вы не используете явную конфигурацию транзакции, например, используя JdbcTemlate или просто ядро Java Statement, транзакция будет создана неявно.
Поэтому, отвечая на ваш вопрос, JPA заставляет использовать транзакцию, чтобы заставить разработчика понять свои действия.
В вашем случае ключевыми словами, чтобы получить ответ, является постоянство состояния сущности. Вот хорошая статья, которая объясняет, как JPA работает с сущностями.
Это не связано с JPA. Он связан с TransactionManager, который вы, вероятно, настроили для работы. JTA-Transactionmanager вместе с EntityManager-Object будет обрабатывать соединения с базой данных и следить за тем, чтобы вы не делали DB-Changes без запуска транзакции.
Сам JPA-Entitymanager содержит методы, которые вы можете использовать для обработки транзакций.
В EntityManager-javadoc вы видите:
TransactionRequiredException - если нет никакой транзакции, когда вызвано на менеджере сущностей, управляемом контейнером, имеет тип PersistenceContextType.TRANSACTION
Таким образом, вы видите, как только вы используете TransactionManager, entitymanager получает управление контейнером.
Также см.: Контейнер Управляемый Entitymanager
Это не связано с JPA. Все операции с базой данных требуют транзакции, каждая из них. Дело в том, что иногда это просто скрыто от вас, как будто вы явно не создаете транзакцию, базовая структура сделает это за вас (это случай выбора сущностей в JPA).
В целом, JPA не заставляет вас, база данных заставляет вас делать это, и это характер СУБД.
Этот вопрос содержит более одного пункта:
- JPA является реализацией для ORM "объектно-реляционного отображения", которое по определению сопоставляет используемые вами объекты с данными в двухстороннем направлении БД, и для этого может возникать решаемые проблемы, которые могут возникнуть, поэтому он вводит транзакции для решения таких проблем.
- (сохранение только одного элемента) не является атомарной операцией, поскольку у вас может быть 2 транзакции, сохраняющие разные данные в одном поле "говорим об обновлении для создания или добавьте свой объект, не отображенный до тех пор, пока вы не вызовете постоянство", или 2 перехода имеют разные грязные значения, поэтому глобально ваш операция сохранения не