Альтернатива Hibernate или TopLink? [закрытый]

есть ли жизнеспособная альтернатива спячке? Предпочтительно что-то, что не основано на JPA.

наша проблема в том, что мы строим сложную (как в, многие объекты ссылаются друг на друга) систему RIA с состоянием. Похоже, что Hibernate предназначен для использования в основном в одноразовых приложениях-JSF и тому подобное.

проблема в основном заключается в ленивой загрузке. Поскольку между инициализацией и фактической загрузкой может быть несколько HTTP-запросов о коллекциях, сеансе на транзакцию не может быть и речи. Длительный сеанс (по одному на приложение) также не работает хорошо, потому что, как только транзакция попадает в загвоздку и выдает исключение, весь сеанс недействителен, таким образом, ленивые загруженные объекты ломаются. Тогда есть все виды вещей, которые просто не работают для нас (например, неявное сохранение данных вне инициализированной транзакции).

мои плохие объяснения в сторону, суть в том, что Hibernate делает магию нам это не нравится. Похоже, что TopLink не лучше, он также написан поверх EJB.

Итак, слой сохранения без состояния (или даже достаточно яркий объектно-ориентированный слой абстракции базы данных) - это то, что нам нужно больше всего.

любые мысли, или я прошу о чем-то, чего не существует?

Edit: извините за мою двусмысленную терминологию, и спасибо всем за ваши исправления и проницательные ответы. Те, кто поправил меня, вы все правильно, я имел в виду JPA, а не EJB.

6
eclipselink hibernate java java-ee jpa

11 ответов

Как уже упоминалось, JPA EJB, они даже не связаны. EJB 3 использует JPA, но это все. У нас есть куча вещей, использующих JPA, которые даже не приближаются к запуску EJB.

ваша проблема не в технологии, это ваш дизайн.

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

в частности, вы пытаетесь сохранить транзакции в течение нескольких HTTP-запросов.

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

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

ваша большая проблема-просто управлять транзакциями вручную.

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

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

Итак, просто, если вы хотите использовать транзакции DB, вам нужно убедиться, что вы используете одно и то же соединение DB.

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

вы хотите, чтобы ваши интерактивные транзакции были кратковременными, как практичными.

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

Это по существу означает, что вам нужно будет придумать свой собственный механизм для "фиксации" ваших данных.

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

между тем, все ваши другие SQL "игнорируют" данные, которые не "сохранены". Бросить в некоторых временных меток и жнец очистки (Если вы действительно хотите беспокоиться-это вполне может быть на самом деле дешевле просто оставить мертвых строки в БД, зависит от объема), эти мертвые" несохраненные " строки, так как это "несохраненные" транзакции.

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

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

6

Если вы ищете другого поставщика JPA (Hibernate-один из них), посмотрите на EclipseLink. Это гораздо более полнофункциональный, чем эталонная реализация JPA 1.0 TopLink Essentials. Фактически, EclipseLink будет эталонной реализацией JPA 2.0, поставляемой с Glassfish V3 Final.

JPA-это хорошо, потому что вы можете использовать его как внутри, так и снаружи контейнера. Я написал клиентов Swing, которые используют JPA для хорошего эффекта. Это не имеет такого же клейма и XML-багаж, с которым пришел EJB 2.0/2.1.

Если вы после еще более легкого решения веса, то смотрите не дальше, чем ibatis, который я считаю своей технологией сохранения выбора для платформы Java. Он легкий, опирается на SQL (удивительно, сколько времени пользователи ORM тратят на то, чтобы их ORM производил хороший SQL) и делает 90-95% того, что делает JPA (включая ленивую загрузку связанных объектов, если вы хотите).

просто исправить пару очки:

  • JPA-это слой перистентности EJB, не построенный на EJB;
  • у любого приличного провайдера JPA есть много кэширования, и может быть трудно понять все это (это был бы хороший пример "почему простота так сложна?"). Если вы не делаете что-то, что вы не indicatd, исключения не должны быть проблемой для ваших управляемых объектов. Исключения времени выполнения обычно откатывают транзакции (если вы используете управление транзакциями Spring, а кто нет сделать это?). Поставщик будет поддерживать кэшированные копии загруженных или сохраненных объектов. Это может быть проблематично, если вы хотите обновить вне диспетчера сущностей (требуется явный сброс кэша или использование EntityManager.refresh()).
7

Я думаю, вы должны взглянуть на apache cayenne что является очень хорошей альтернативой" большим " фреймворкам. С его достойным моделистом кривая обучения сокращается хорошей документацией.

3

Я посмотрел на SimpleORM в прошлом году, и был очень впечатлен его легкий дизайн без магии. Теперь, кажется, есть версия 3, но у меня нет никакого опыта с этим.

2

Ebean ORM (http://www.avaje.org)

Это более простой и интуитивно понятный ORM для использования.

  • использует аннотации JPA для отображения (@Entity, @OneToMany и т. д.)
  • API-интерфейс без сеансов - не Hibernate-сессий или СПД диспетчер сущностей
  • отложенная загрузка работает
  • частичная поддержка объектов для повышения производительности
  • автоматическая настройка запросов через "Autofetch"
  • Весна Интеграции
  • большие Поддержка Запросов
  • отличная поддержка пакетной обработки
  • фон выборки
  • поколение DDL
  • вы можете использовать raw SQL, если хотите (так же хорошо, как Ibatis)

  • лицензия LGPL

  • Роб.

2

BEA Kodo (formerlly Solarmetric Kodo) - еще одна альтернатива. Он поддерживает JPA, JDO и EJ3. Она высоки конфигурируема и может поддержать агрессивный pre-fetching, разделять/прикрепляться предметов, etc.

хотя, из того, что вы описали, Toplink должен быть в состоянии справиться с вашими проблемами. В основном, похоже, что вам нужно иметь возможность присоединять/отсоединять объекты от слоя сохраняемости при запуске и завершении запросов.

1

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

1

ни Hibernate, ни Toplink (EclipseLink) не основаны на EJB, они оба POJO persistancy Framework (ORM).

Я согласен с предыдущим ответом: iBatis-хорошая альтернатива ORM-фреймворкам: полный контроль над sql с хорошим механизмом кэширования.

0

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

крутящий момент

0

когда я сам искал замену для спячки, я наткнулся на Платформа Доступа К DataNucleus, который является лицензированным ORM Apache2. Это не просто ORM, поскольку он обеспечивает сохранение и извлечение данных также в других источниках данных, чем СУБД, таких как LDAP, DB4O и XML. У меня нет никакого опыта использования, но это выглядит интересно.

0

рассмотрите возможность полного разрыва вашей парадигмы с чем-то вроде tox. Если вам нужны классы Java, вы можете загрузить результат XML в помощи jdom.

0