Исключение «неподдерживаемое использование GenericConnection» при переходе с JPA2.0 на JPA 2.1

Question

Мы осуществляем переход с WAS 8.5 (в котором используется openJPA для JPA 2.0, Hibernate 4.2.x [последняя версия JPA 2.0]) на WAS 9.0 ( который использует eclipseLink для JPA 2.1 и Hibernate 5.2.18 [последняя версия JPA 2.1]) и, кроме одного, миграция прошла успешно.

Чтобы сделать возможным Развертывая одно и то же приложение несколько раз на сервере и работая с разными базами данных, мы определили переменную DataSource ссылка в persistence.xml:

  <persistence-unit name="App_DB" transaction-type="JTA">

    <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
    <jta-data-source>java:comp/env/jdbc/app/dataSourceRef</jta-data-source>

    <properties>
      <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle12cDialect" />
      <property name="connection.autocommit" value="false" />           

      <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.WebSphereExtendedJTATransactionLookup" />
      <property name="jta.UserTransaction" value="java:comp/UserTransaction" />

      <property name="hibernate.hbm2ddl.auto" value="validate" />
      <property name="javax.persistence.validation.mode" value="none" />
    </properties>

  </persistence-unit>

Как видите, <jta-data-source> является ссылкой. Ссылка связана в ibm-ejb-jar-bnd.xml

<session name="StartUpService">
  <resource-ref name="jdbc/app/dataSourceRef" binding-name="jdbc/app/appDB"/>
</session>

и используется в классе следующим образом:

@Singleton
@Startup
@LocalBean
public class StartUpService {

  @Resource(name = "jdbc/app/dataSourceRef", type = DataSource.class)
  DataSource dataSource;  

}

Это прекрасно работало для WAS 8.5 / openJPA . Но при использовании WAS 9.0 / eclipseLink это больше не работает и вызывает следующие исключения при попытке запустить приложение:

[WebContainer: 4] ОШИБКА org.hibernate.hql.spi.id.IdTableHelper - Невозможно использовать JDB C Соединение для создания оператора java. sql .SQLException: Неподдерживаемое использование GenericConnection. GenericConnection предоставляется во время запуска приложения при создании EntityManagerFactory для модуля персистентности, который настроил один из своих источников данных в контекст именования компонентов; java: комп / окр. Во время запуска приложения контекст именования компонента не будет существовать, и правильный источник данных не может быть определен. Когда используется постоянный модуль, будут получены и использованы надлежащий источник данных и соединение. на com.ibm.ws.jpa.management.GenericConnection.unsupportedUseSQLException (GenericConnection. java: 636) ~ [com.ibm.ws.runtime.jar :?] на com.ibm.ws.jpa.management.GenericConnection. createStatement (GenericConnection. java: 144) ~ [com.ibm.ws.runtime.jar :?] at org.hibernate.hql.spi.id.IdTableHelper.executeIdTableCreationStatements (IdTableHelper. java: 77) [org. hibernate-hibernate-core-5.2.18.Final.jar: 5.2.18.Final] at org.hibernate.hql.spi.id.global.GlobalTeilitaryTableBulkIdStrategy.finishPreperation (GlobalTeilitaryTableBulkIdStrategy. java: 125) [org.hiber hibernate-core-5.2.18.Final.jar: 5.2.18.Final] в org.hibernate.hql.spi.id.global.GlobalTeventTableBulkIdStrategy.finishPreperation (GlobalTeilitaryTableBulkIdStrategy. java: 42) [org.hibernate-hiber core-5.2.18.Final.jar: 5.2.18.Final] в org.hibernate.hql.spi.id.AbstractMultiTableBulkIdStrategyImpl.prepare (AbstractMultiTableBulkIdStrategyImpl. java: 88) [org.hibernate-hibernate-core-5.2. 18.Final.jar: 5.2.18.Final] в org.hibern ate.internal.SessionFactoryImpl. (SessionFactoryImpl. java: 305) [org.hibernate-hibernate-core-5.2.18.Final.jar: 5.2.18.Final] в org.hibernate.boot.internal.SessionFactoryBuilderImpl.build (SessionFactoryBuilderImpl. java: 462) [org.hibernate-hibernate-core-5.2.18.Final.jar: 5.2.18.Final] в org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build (EntityManagerFactory). 1108 *: 945) [org.hibernate-hibernate-core-5.2.18.Final.jar: 5.2.18.Final] в org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory (HibernatePersistenceProvider. java: 151) [org. hibernate-hibernate-core-5.2.18.Final.jar: 5.2.18.Final] на com.ibm.ws.jpa.management.JPAPUnitInfo.createEMFactory (JPAPUnitInfo. java: 1161) [com.ibm.ws. runtime.jar:?]

 [...]

на com.ibm.ws.util.ThreadPool $ Worker.run (ThreadPool. java: 1909) [com.ibm.ws.runtime.jar :? ]

[WebContainer: 4] ОШИБКА org.hibernate.engine.jdb c .spi.SqlExceptionHelper - Неподдерживаемое использование GenericConnec Тион. GenericConnection предоставляется во время запуска приложения при создании EntityManagerFactory для модуля персистентности, который настроил один из своих источников данных в контекст именования компонентов; java: комп / окр. Во время запуска приложения контекст именования компонента не будет существовать, и правильный источник данных не может быть определен. Когда используется модуль персистентности, будут получены и использованы надлежащие источник данных и соединение.

000000a1 JPAPUnitInfo E CWWJP0015E: В поставщике персистентности org.hibernate.jpa.HibernatePersistenceProvider произошла ошибка при попытке создать контейнер. фабрика менеджера сущностей для модуля персистентности App_DB. Произошла следующая ошибка: [PersistenceUnit: App_DB] Невозможно построить Hibernate SessionFactory

Так что, похоже, Hibernate не может определить DataSource. Когда я устанавливаю полное JDNI-имя <jta-data-source> вместо ссылки, подобной этой

<jta-data-source>jdbc/app/appDB</jta-data-source> 

, приложение запускается отлично, и Hibernate может выполнять проверку схемы и все при запуске.

Когда я искал эту проблему на net, я нашел предложение , что вы должны добавить javax.persistence.jtaDataSource" к persistence.xml с тем же значением, что и <jta-data-source>, как это:

<property name="javax.persistence.jtaDataSource" value="java:comp/env/jdbc/app/dataSourceRef" />

Но это ничего не изменило в моем случае. Та же ошибка и отсутствие успешного запуска.

Поэтому мне интересно получить ответы на следующие вопросы:

1. Основной вопрос: Как мне определить мой persistence.xml для снова использовать ссылку DataSource? Это не помогает, если проверка запуска выполняется для одной и той же базы данных для всех экземпляров приложения, даже если запущенное приложение будет использовать другой источник данных после запуска, потому что я, очевидно, хочу проверить DataSource, который экземпляр действительно использует , Примечание: Изменение реализации JPA не будет сделано нашими администраторами - они будут придерживаться только первоначальной причины конфигурации поддержки IBM.

2. Незначительный вопрос: почему Hibernate (4.2.x) в сочетании с openJPA может использовать ссылку в WAS 8.5 , но Hibernate (5.2.18) в комбинация с eclipseLink не может сделать это в БЫЛ 9.0 ?

Answer 1

Go дайте обновление об этом. Мой пост - не ответ с рабочим решением, но с дополнительными объяснениями, которые происходят (насколько я понимаю) и почему это не удается. И сказать это, прежде чем это будет краткая версия моего анализа, я написал для работы (более 4 страниц), так как я не хотел переводить полностью с немецкого (мой engli sh довольно плохой), и они основаны на нескольких файлах журнала Я не могу опубликовать sh здесь.

td; др

IBM должна изменить WAS 9.

Длинная история

После очередного разговора с нашими администраторами я провел дополнительное исследование:

Ошибка Unsupported use of GenericConnection выдается IBM и даже была выдана на WAS 8.5 / Hibernate 4.2.x, но Комбинация WAS / Hiberante работала по-другому, как в 9.0 / 5.2.x

Ошибка Unable to use JDBC Connection to create Statement выдается (в 5.2) IdTableHelper при попытке создать инструкцию для объекта соединения (Statement statement = connection.createStatement();), который был создан EntityManagerFactory. Мне было интересно, почему одна ошибка говорит, что не может обеспечить соединение? Я пришел к выводу, что WAS возвращает какой-то элемент прокси, в противном случае, если соединение будет NULL, сообщение об ошибке будет Unable obtain JDBC Connection, которое будет инициировано ранее в коде Hibernates.

Дальнейшие исследования :

Когда приложение запускается (например, нажав start в консоли администратора), начальная фаза состоит из двух фаз: в первой запускается контейнер, возвращая EJB, JTA JMS, JPA et c. и после этого приложение запускается и запускаются все компоненты запуска (компоненты, помеченные @StartUp). При возникновении ошибки, которую WAS считает критической, при запуске происходит сбой.

Hibernates пытается проверить схему (на hbm2dll=validate) при создании управления предприятием.

При копании в дальнейших журналах я обнаружил, что в Hibernate 4.2 дважды возникала ошибка при настройке JPA, так как не было соединения, но при запуске bean-компонента журналы показывают, что persistence.xml анализируется снова и соединение может быть предоставлено WAS , В связи с этим проверка схемы прошла успешно. Во время настройки JPA сообщение об ошибке появляется дважды, потому что получение метаданных и попытка проверки находятся в двух блоках try / catch в Hibernate 4.2.

При использовании WAS9 / Hibernate 5.2 сообщение об ошибке регистрируется и запускается failes. Сообщение регистрируется только один раз, потому что получение метаданных и проверка выполняются в одном и том же блоке try / catch, и это уже не удается при получении метаданных. Эта ошибка по-прежнему не нарушает запуск приложения. Но в отличие от WAS 8.5 / 4.2, когда запускающий компонент запускается, процесс запуска завершается ошибкой, так как никакой компонент управления данными не может быть предоставлен компоненту. Также логи показывают, что persistence.xml больше не анализируется. Таким образом, WAS не пытается предоставить диспетчер сущностей во второй раз.

Таким образом, без «исправления» или, назовем это изменением WAS 9, использование datasource-refrence невозможно. И я сомневаюсь, что это когда-нибудь случится ...

На более:

Упомянутый класс IdTableHelper является базовой c девушкой для стратегии Hibernates Bulk и два метода, которые может быть выдано сообщение об ошибке, попробуйте выполнить операторы create или delete. Поскольку пользователь базы данных приложения не имеет прав DDL, я подумал, будет ли это проблемой, и можно ли изменить поведение, изменив массовую стратегию спящего режима на org.hibernate.hql.spi.id.inline.InlineIdsInClauseBulkIdStrategy, где не создаются таблицы для каскадных операций. Но это ничего не изменило, поскольку метаданные для проверки схемы по-прежнему необходимы.