Мне было интересно, есть ли у кого-нибудь опыт реализации JPA2.0 любой из этих фреймворков? Особенно вместе с Spring3.x, который поставляется с поддержкой EclipseLink.
Используете ли вы какие-либо из этих фреймворков и JPA2.0 для производства? Любые серьезные проблемы?
ИМХО Всегда лучше использовать стандартный api, где это возможно. Ваш собственный пример показывает это отлично. Вы смогли попробовать ваш идентичный код на двух провайдерах, если он не работал должным образом. Переключение на любой собственный API не позволяет вам это делать.
Если использование EclipseLink в качестве поставщика JPA 2.0 хорошо работает для вас, используйте его. Если вы столкнулись с проблемой, напишите ошибку EclipseLink и получите справку на этом форуме или на форумах EclipseLink и в новостных группах.
EclipseLink более совместим со стандартами, поскольку эталонная реализация для JPA 2, Hibernate имеет некоторые проблемы с совместимостью, но более зрелая.
Одним из основных преимуществ EclipseLink является то, что вы можете вызывать собственные SQL-функции непосредственно в ваших запросах JPQL. В Hibernate это невозможно.
Но Hibernate имеет большее сообщество, лучшую документацию и также улучшает сообщения об ошибках.
Из моего опыта, с профилированием Java Perf. Мои приложения, созданные с использованием Eclipselink, похоже, намного лучше, чем с Hibernate, как при вставке и извлечении данных. Однако Hibernate более широко используется и предоставляет более широкий форум для поддержки.
В производстве я просто возьму Hibernate по этой причине.
Просто выберите и придерживайтесь одного. Стандарты - это только конечные рекомендации, и каждый разработчик может реализовать или не выполнить соответствующие стандарты.
например.
У EclipseLink есть проблемы с использованием чего-то основного, такого как JPA @Converter, хотя предположительно недавно исправлено через IBM http://www-01.ibm.com/support/docview.wss?uid=swg1PI73277
Реализация Hibernate JPQL не понимает логических значений, которые стоят отдельно, я должен был изменить свой JPQL, чтобы сказать
from Participant p where not p.cancelled
к
from Participant p where p.cancelled = false
Другое дело, что вы строите вещи в Spring, и вы, скорее всего, собираетесь использовать ненадлежащий, но общий подход, чтобы изменить загрузчик классов на PARENT_LAST, чтобы ваши классы использовались, а не серверы приложений.
Если вы планируете сделать правильный путь и используете JPA, который поставляется с сервером приложений, просто немного опасайтесь, что реализация вашего сервера приложений может быть ошибкой.
Транзакция, использующая ваше приложение, в частности, Spring должна обрабатывать вещи для вас.