Разница между "источником данных jta" и "локальным ресурсом"?

Question

Термины "jta-datasource" и "resource-local datasource" для меня немного расплывчаты. Я записываю то, что понимаю (или предполагаю), и я бы хотел, чтобы вы сказали, где я прав / неправ.

• Одна и та же база данных может называться источником данных jta или локальным источником данных ресурса.
• Если упомянуто как jta-datasource, то бины / другие классы могут использовать JTA. Следовательно, интерфейс UserTransaction
• Невозможно использовать CMT / BMT, если источник данных является локальным ресурсом
• Если упомянуто как источник локального источника данных, транзакции не поддерживаются JTA. Код может использовать интерфейс EntityTransaction, но не интерфейс UserTransaction

Спасибо!

Answer 1

Термины "jta-datasource" и "resouce-local datasource" для меня немного расплывчаты.

Я полагаю, вы на самом деле ссылаетесь на jta-datasource а также non-jta-datasource элементы. Короче:

• если тип транзакции единицы постоянства - JTA, jta-datasource Элемент используется для объявления имени JNDI источника данных JTA, который будет использоваться для получения соединений. Это частый случай.
• если тип транзакции модуля персистентности является локальным для ресурса, non-jta-data-source должен использоваться для объявления имени JNDI источника данных не-JTA.

• Одна и та же база данных может называться источником данных jta или локальным источником данных ресурса.

Это правильно. И я не упомянул это чуть выше, но некоторые провайдеры даже позволяют объявить как jta-datasource и non-jta-datasource и использовать последнее для оптимизированного чтения через не-JTA-соединения (т.е. это не будет связано с текущей транзакцией JTA).

• Если упомянуто как jta-datasource, то бины / другие классы могут использовать JTA. Следовательно, интерфейс UserTransaction.

Первая часть верна, последняя часть не совсем. Из спецификации EJB 3.0, раздел 13.3.4 Enterprise Beans, использующий разграничение транзакций, управляемых контейнером:

Деловые методы корпоративного бина [...] не должны пытаться получить или использовать javax.transaction.UserTransaction интерфейс.

И раздел 16.12 Интерфейс UserTransaction:

Контейнер не должен делать UserTransaction Интерфейс доступен корпоративным компонентам, которым не разрешено использовать этот интерфейс.

Другими словами, UserTransaction интерфейс недоступен для корпоративных бинов CMT.

• Невозможно использовать CMT / BMT, если источник данных является локальным ресурсом

Формулировка здесь немного запутанная, но я бы сказал, что это не совсем правильно. Из спецификации JPA 1.0, раздел § 5.5 Управление транзакциями:

Менеджер объекта, управляемого приложением, может быть либо администратором объекта JTA, либо администратором объекта локального ресурса.

...

Как менеджеры сущностей JTA, так и менеджеры сущностей локальных ресурсов должны поддерживаться в веб-контейнерах Java EE и EJB-контейнерах. В среде EJB обычно используется менеджер сущностей JTA.

И раздел 6.2.1.2 тип транзакции

transaction-type Атрибут используется для указания того, должны ли менеджеры сущностей, предоставляемые фабрикой менеджеров сущностей для единицы сохраняемости, быть менеджерами сущностей JTA или локальными менеджерами сущностей ресурсов. Значение этого элемента JTA или же RESOURCE_LOCAL, Тип транзакции JTA предполагает, что будет предоставлен источник данных JTA - либо как указано в jta-data-source элемент или предоставляется контейнером. Как правило, в средах Java EE transaction-type из RESOURCE_LOCAL предполагает, что будет предоставлен источник данных не JTA. В среде Java EE, если этот элемент не указан, по умолчанию используется JTA.

Таким образом, вы МОЖЕТЕ использовать диспетчер управляемых сущностей приложения, который может быть локально-ресурсным менеджером сущностей (вы должны ввести EntityManagerFactory чтобы получить EM от этого в этом случае), и это не будет частью транзакции JTA. Смотрите это (очень интересное) обсуждение.

• Если упомянуто как источник локального источника данных, транзакции не поддерживаются JTA. Код может использовать интерфейс EntityTransaction, но не интерфейс UserTransaction

Опять же, формулировка немного сбивает с толку, но я бы сказал, что это правильно.