Альтернатива Hibernate или TopLink?[закрыто]
https://stackoverflow.com/questions/413131
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Есть ли жизнеспособная альтернатива гибернации?Предпочтительно что-то, что не основано на JPA.
Наша проблема заключается в том, что мы создаем сложную (например, многие объекты ссылаются друг на друга) систему RIA с сохранением состояния.Похоже, что Hibernate предназначен для использования в основном в одноразовых приложениях - JSF и тому подобном.
Проблема в основном заключается в отложенной загрузке.Поскольку между инициализацией и фактической загрузкой отложенных коллекций может быть несколько HTTP-запросов, о сеансе для каждой транзакции не может быть и речи.Длительный сеанс (по одному на приложение) также плохо работает, потому что, как только транзакция натыкается на препятствие и выдает исключение, весь сеанс становится недействительным, таким образом, лениво загруженные объекты прерываются.Кроме того, есть всевозможные вещи, которые просто не работают для нас (например, неявное сохранение данных извне инициализированной транзакции).
Если отбросить мои скудные объяснения, суть в том, что Hibernate творит магию, которая нам не нравится.Похоже, TopLink ничуть не лучше, он также написан поверх EJB.
Итак, уровень сохраняемости без сохранения состояния (или даже достаточно яркий уровень объектно-ориентированной абстракции базы данных) - это то, что нам понадобится больше всего.
Есть какие-нибудь мысли, или я прошу о чем-то, чего не существует?
Редактировать: Я прошу прощения за свою двусмысленную терминологию и благодарю всех вас за ваши исправления и содержательные ответы.Те, кто меня поправил, вы все правы, я имел в виду JPA, а не EJB.
Решение
Как уже упоминалось, JPA < > EJB, они даже не связаны. EJB 3 использует JPA, но это все. У нас есть куча вещей, использующих JPA, которые даже близко не подходят к запуску EJB.
Ваша проблема не в технологии, а в вашем дизайне.
Или, я должен сказать, ваш дизайн не очень удобен для ЛЮБОГО современного фреймворка.
В частности, вы пытаетесь поддерживать транзакции в течение нескольких HTTP-запросов.
Естественно, что большинство распространенных идиом заключается в том, что каждый запрос представляет собой одну или несколько транзакций, а не каждый запрос является частью более крупной транзакции.
Существует также очевидная путаница, когда вы используете термин " без сохранения состояния " и " транзакция " в том же обсуждении, так как транзакции по своей сути с учетом состояния.
Ваша большая проблема - просто управлять своими транзакциями вручную.
Если ваша транзакция происходит по нескольким HTTP-запросам, и эти HTTP-запросы выполняются " очень быстро ", сразу после друг друга, то у вас действительно не должно быть никаких реальных проблем За исключением того, что вам потребуется убедиться, что ваши HTTP-запросы используют одно и то же соединение с БД, чтобы использовать средство транзакций Базы данных.
То есть, говоря простым языком, вы получаете соединение с БД, заполняете его в сеансе и убедитесь, что в течение транзакции все ваши HTTP-запросы проходят не только в том же сеансе, но и в таким образом, что фактическое соединение все еще действует. В частности, я не верю, что есть готовое JDBC-соединение, которое фактически переживет отказоустойчивость или балансировку нагрузки с одной машины на другую.
Итак, просто, если вы хотите использовать транзакции с БД, вам нужно убедиться, что вы используете одно и то же соединение с БД.
Теперь, если ваша длительная транзакция имеет " взаимодействия с пользователем " внутри него, т. е. вы запускаете транзакцию БД и ждете, пока пользователь не "& сделает что-то &", а затем просто скажет, что дизайн ошибочен. Вы НЕ хотите этого делать, поскольку долгоживущие транзакции, особенно в интерактивных средах, просто плохие. Например, & Quot; Crossing The Streams & Quot; Плохой. Не делай этого. Пакетные транзакции отличаются, но интерактивные долгоживущие транзакции плохие.
Вы хотите, чтобы ваши интерактивные транзакции были как можно более короткими.
Теперь, если вы НЕ МОЖЕТЕ гарантировать, что сможете использовать одно и то же соединение с БД для своей транзакции, тогда, поздравляю, вы можете реализовать свои собственные транзакции. Это означает, что вы можете спроектировать свою систему и потоки данных так, как будто у вас нет транзакционных возможностей на бэкэнде.
По сути это означает, что вам нужно будет придумать свой собственный механизм для " commit " ваши данные.
Хорошим способом сделать это было бы, когда вы постепенно собираете свои данные в одну & транзакцию " document, затем передайте этот документ в " save " рутина, которая делает большую часть реальной работы. Например, вы можете сохранить строку в базе данных и пометить ее как & Quot; unsaved & Quot ;. Вы делаете это со всеми своими строками и, наконец, вызываете подпрограмму, которая пробегает все данные, которые вы только что сохранили, и помечает все это как & Quot; сохраненный & Quot; в мини-пакетном процессе одной транзакции.
Между тем все остальные ваши SQL " игнорируют " данные, которые не являются & сохраненными &. Добавьте некоторые временные метки и очистите процесс повторения (если вы действительно хотите беспокоиться - может быть, на самом деле дешевле просто оставить мертвые строки в БД, зависит от объема), эти мертвые & Quot; unsaved Quot; строки, так как они являются " uncomited " сделки.
Это не так плохо, как кажется. Если вы действительно хотите среду без гражданства, как мне кажется, вам нужно сделать что-то подобное.
Имейте в виду, во всем этом технология настойчивости действительно не имеет ничего общего ст. Проблема в том, как вы используете свои транзакции, а не как технологии.
Другие советы
Если вам нужен другой поставщик JPA (Hibernate является одним из них), то взгляните на Ссылка на затмение.Он гораздо более полнофункциональный, чем эталонная реализация TopLink Essentials в JPA 1.0.Фактически, EclipseLink будет эталонной реализацией JPA 2.0, поставляемой вместе с Glassfish V3 Final.
JPA хорош тем, что вы можете использовать его как внутри, так и снаружи контейнера.Я написал Swing-клиенты, которые используют JPA с хорошим эффектом.У него нет той стигматизации и XML-багажа, с которыми поставляется EJB 2.0 / 2.1.
Если вам нужно еще более легкое решение, то смотрите не дальше ибатис, которую я считаю своей предпочтительной технологией сохранения для платформы Java.Он легкий, опирается на SQL (удивительно, сколько времени пользователи ORM тратят, пытаясь заставить свой ORM выдавать хороший SQL) и выполняет 90-95% того, что делает JPA (включая отложенную загрузку связанных объектов, если хотите).
Просто исправлю пару моментов:
- JPA - это постоянный уровень EJB, не построенный на EJB;
- У любого приличного JPA-провайдера происходит огромное количество кэширования, и разобраться во всем этом может быть трудно (это было бы хорошим примером того, "Почему простота настолько сложна?").Если вы не делаете что-то, чего не указали, исключения не должны быть проблемой для ваших управляемых объектов.Исключения среды выполнения обычно откатывают транзакции (если вы используете управление транзакциями Spring, а кто этого не делает?).Поставщик будет поддерживать кэшированные копии загруженных или сохраненных объектов.Это может быть проблематично, если вы хотите выполнить обновление вне entity manager (требуется явная очистка кэша или использование
EntityManager.refresh()).
Я думаю, вам стоит взглянуть на apache cayenne , который является очень хорошей альтернативой & Quot; & большой Quot; рамки. Благодаря приличному моделированию, кривая обучения сокращается благодаря хорошей документации.
Я смотрел на SimpleORM в прошлом году и был очень впечатлен его легким, не волшебным дизайном , Сейчас, кажется, есть версия 3, но у меня нет никакого опыта с этим.
Ebean ОРМ (http://www.avaje.org)
Это более простой и интуитивно понятный ORM в использовании.
- Использует аннотации JPA для сопоставления (@Entity, @OneToMany и т.д.)
- Бессессионный API - нет сеанса гибернации или диспетчера объектов JPA
- Отложенная загрузка просто работает
- Частичная поддержка объектов для повышения производительности
- Автоматическая настройка запроса с помощью "Автоматической выборки"
- Весенняя интеграция
- Поддержка больших запросов
- Отличная поддержка пакетной обработки
- Выборка фона
- Генерация DDL
- Вы можете использовать необработанный SQL, если хотите (не хуже Ibatis).
Лицензия LGPL
Роб.
BEA Kodo (ранее Solarmetric Kodo) является еще одной альтернативой. Он поддерживает JPA, JDO и EJ3. Он легко настраивается и может поддерживать агрессивную предварительную выборку, отсоединение / присоединение объектов и т. Д.
Тем не менее, из того, что вы описали, Toplink должен справиться с вашими проблемами. По большей части это звучит так, как будто вы должны иметь возможность присоединять / отсоединять объекты от слоя постоянства, когда запросы начинаются и заканчиваются.
Просто для справки, почему дизайн OP является его самой большой проблемой: охват транзакций несколькими запросами пользователя означает, что вы можете иметь столько открытых транзакций в данный момент времени, сколько пользователей подключено к вашему приложению - транзакция поддерживает соединение занятым до оно зафиксировано / отменено. С тысячами одновременно подключенных пользователей это может потенциально означать тысячи подключений. Большинство баз данных не поддерживают это.
Ни Hibernate, ни Toplink (EclipseLink) не основаны на EJB, они оба являются средами постоянства POJO (ORM).
Я согласен с предыдущим ответом: iBatis - хорошая альтернатива средам ORM: полный контроль над SQL, с хорошим механизмом кэширования.
Еще один вариант - Torque, я не говорю, что он лучше, чем любой из упомянутых выше вариантов, но просто это другой вариант. Сейчас он довольно стар, но может соответствовать некоторым вашим требованиям.
Когда я сам искал замену Hibernate, я наткнулся на Платформу доступа к DataNucleus , который является лицензированным Apache2 ORM. Это не просто ORM, поскольку он обеспечивает постоянство и извлечение данных и из других источников данных, кроме СУБД, таких как LDAP, DB4O и XML. У меня нет опыта использования, но это выглядит интересно.
