¿Una alternativa a Hibernate o TopLink? [cerrado]

StackOverflow https://stackoverflow.com/questions/413131

Pregunta

¿Existe una alternativa viable a Hibernate? Preferiblemente algo que no se base en JPA.

Nuestro problema es que estamos construyendo un sistema RIA con estado complejo (como muchos objetos se refieren entre sí). Parece que Hibernate está diseñado para usarse principalmente en aplicaciones únicas: JSF y similares.

El problema es principalmente el de la carga diferida. Dado que puede haber varias solicitudes HTTP entre la inicialización y la carga de colecciones diferidas, una sesión por transacción está fuera de discusión. Una sesión de larga duración (una por aplicación) tampoco funciona bien, porque una vez que una transacción golpea un obstáculo y arroja una excepción, toda la sesión se invalida, por lo que los objetos con carga lenta se rompen. Luego, hay todo tipo de cosas que simplemente no funcionan para nosotros (como los datos implícitos que persisten de fuera de una transacción inicializada).

Dejando de lado mis pobres explicaciones, la conclusión es que Hibernate hace magia que no nos gusta. Parece que TopLink no es mejor, también está escrito encima de EJB.

Entonces, una capa de persistencia sin estado (o incluso una capa de abstracción de base de datos orientada a objetos lo suficientemente brillante) es lo que más necesitaríamos.

¿Alguna idea, o estoy pidiendo algo que no existe?

Editar: lo siento por mi ambigua terminología, y gracias a todos por sus correcciones y respuestas perspicaces. Aquellos que me corrigieron, ustedes están en lo correcto, quise decir JPA, no EJB.

¿Fue útil?

Solución

Como se mencionó, JPA < > EJB, ni siquiera están relacionados. EJB 3 aprovecha el JPA, pero eso es todo. Tenemos un montón de cosas usando JPA que ni siquiera se acerca a ejecutar EJB.

Tu problema no es la tecnología, es tu diseño.

O, debo decir, su diseño no se ajusta fácilmente a CUALQUIER marco moderno.

Específicamente, está intentando mantener las transacciones vivas en varias solicitudes HTTP.

Naturalmente, la mayoría de las expresiones comunes es que cada solicitud es en sí misma una o más transacciones, en lugar de que cada solicitud sea una parte de una transacción más grande.

También hay una confusión obvia cuando usas el término " sin estado " y " transacción " en la misma discusión, ya que las transacciones son inherentemente con estado.

Su gran problema es simplemente administrar sus transacciones manualmente.

Si su transacción se produce a través de varias solicitudes HTTP, Y esas solicitudes HTTP se ejecutan & "; muy rápidamente &"; uno tras otro, entonces realmente no debería tener ningún problema real , guarde que tendrá que asegurarse de que sus solicitudes HTTP estén utilizando la misma conexión de base de datos para aprovechar el recurso de transacción de bases de datos.

Es decir, en términos simples, obtiene una conexión a la base de datos, la carga en la sesión y se asegura de que durante la transacción, todas sus solicitudes HTTP pasen no solo por la misma sesión, sino en de tal manera que la conexión real sigue siendo válida. Específicamente, no creo que haya una conexión JDBC lista para usar que realmente sobreviva a la conmutación por error o al equilibrio de carga de una máquina a otra.

Entonces, simplemente, si desea utilizar transacciones de base de datos, debe asegurarse de que está utilizando la misma conexión de base de datos.

Ahora, si su transacción de larga duración tiene " interacciones del usuario " dentro de él, es decir, inicia la transacción de base de datos y espera a que el usuario & "; haga algo &"; luego, simplemente, ese diseño está completamente mal. NO DESEA hacer eso, ya que las transacciones de larga duración, especialmente en entornos interactivos, son simplemente malas. Como & Quot; Crossing The Streams & Quot; Malo. No lo hagas Las transacciones por lotes son diferentes, pero las transacciones interactivas de larga duración son malas.

Desea mantener sus transacciones interactivas tan cortas como sea práctico.

Ahora, si NO puede asegurarse de que podrá usar la misma conexión de base de datos para su transacción, felicidades, puede implementar sus propias transacciones. Eso significa que puede diseñar su sistema y los flujos de datos como si no tuviera capacidad transaccional en el back-end.

Eso esencialmente significa que necesitará crear su propio mecanismo para " commit " sus datos.

Una buena manera de hacer esto sería cuando acumule sus datos de forma incremental en una sola " transacción " documento, luego alimente ese documento a " save " rutina que hace gran parte del trabajo real. Por ejemplo, puede almacenar una fila en la base de datos y marcarla como & Quot; no guardado & Quot ;. Lo hace con todas sus filas, y finalmente llama a una rutina que ejecuta todos los datos que acaba de almacenar, y lo marca todo como & "; Guardado &"; en un proceso de mini-lote de transacción única.

Mientras tanto, todos sus otros SQL " ignora " datos que no son " guardados " ;. Agregue algunas marcas de tiempo y tenga un proceso de recolección de residuos segador (si realmente desea molestarse, puede ser realmente más barato dejar filas inactivas en el DB, depende del volumen), estas & Quot; sin guardar quot; filas, ya que estas son " no comprometido " transacciones.

No es tan malo como parece. Si realmente desea un entorno sin estado, que es lo que me parece, entonces tendrá que hacer algo como esto.

Cuidado, en todo esto la tecnología de persistencia realmente no tiene nada que ver con it. El problema es cómo usa sus transacciones, en lugar de tanto la tecnología.

Otros consejos

Si está buscando otro proveedor de JPA (Hibernate es uno de estos), eche un vistazo a EclipseLink . Es mucho más completo que la implementación de referencia JPA 1.0 de TopLink Essentials. De hecho, EclipseLink será la implementación de referencia JPA 2.0 incluida con Glassfish V3 Final.

JPA es bueno porque puedes usarlo tanto dentro como fuera de un contenedor. He escrito clientes Swing que usan JPA con buenos resultados. No tiene el mismo estigma y bagaje XML con el que vino EJB 2.0 / 2.1.

Si buscas una solución aún más ligera, no busques más que ibatis , que considero ser mi tecnología de persistencia preferida para la plataforma Java. Es liviano, se basa en SQL (es sorprendente cuánto tiempo pasan los usuarios de ORM tratando de hacer que su ORM produzca un buen SQL) y hace 90-95% de lo que hace JPA (incluida la carga diferida de entidades relacionadas si lo desea).

Solo para corregir un par de puntos:

  • JPA es la capa de permanencia de EJB, no construida en EJB;
  • Cualquier proveedor de JPA decente tiene una gran cantidad de almacenamiento en caché y puede ser difícil resolverlo todo (este sería un buen ejemplo de & "; ¿Por qué la simplicidad es tan compleja? &";) . A menos que esté haciendo algo que no haya indicado, las excepciones no deberían ser un problema para sus objetos administrados. Las excepciones de tiempo de ejecución suelen revertir las transacciones (si usa la administración de transacciones de Spring y quién no hace eso). El proveedor mantendrá copias en caché de objetos cargados o persistentes. Esto puede ser problemático si desea actualizar fuera del administrador de la entidad (que requiere un vaciado de caché explícito o el uso de EntityManager.refresh()).

Creo que debería echar un vistazo a apache cayenne , que es una muy buena alternativa a " grande " marcos. Con su modelador decente, la curva de aprendizaje se acorta con una buena documentación.

He visto SimpleORM el año pasado, y me impresionó mucho su diseño liviano sin magia . Ahora parece que hay una versión 3, pero no tengo ninguna experiencia con esa.

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

Es un ORM más simple e intuitivo de usar.

  • utiliza anotaciones JPA para la asignación (@Entity, @OneToMany, etc.)
  • API sin sesión: sin sesión de Hibernate o JPA Entity Manager
  • La carga diferida simplemente funciona
  • Soporte de objetos parciales para un mayor rendimiento
  • Ajuste automático de consultas a través de " Autofetch "
  • Integración de primavera
  • Soporte de consultas grandes
  • Gran soporte para el procesamiento por lotes
  • Recuperación de fondo
  • Generación DDL
  • Puede usar SQL sin formato si lo desea (tan bueno como Ibatis)

  • Licencia LGPL

  • Rob.

BEA Kodo (anteriormente Solarmetric Kodo) es otra alternativa. Es compatible con JPA, JDO y EJ3. Es altamente configurable y puede admitir la búsqueda previa agresiva, la separación / fijación de objetos, etc.

Sin embargo, por lo que ha descrito, Toplink debería poder manejar sus problemas. En su mayoría, parece que necesita poder adjuntar / separar objetos de la capa de persistencia a medida que las solicitudes comienzan y finalizan.

Solo como referencia, por qué el diseño del OP es su mayor problema: abarcar transacciones entre múltiples solicitudes de usuarios significa que puede tener tantas transacciones abiertas en un momento dado como usuarios conectados a su aplicación; una transacción mantiene la conexión ocupada hasta está comprometido / revertido. Con miles de usuarios conectados simultáneamente, esto puede significar miles de conexiones. La mayoría de las bases de datos no admiten esto.

Ni Hibernate ni Toplink (EclipseLink) se basan en EJB, ambos son marcos de persistencia POJO (ORM).

Estoy de acuerdo con la respuesta anterior: iBatis es una buena alternativa a los marcos ORM: control total sobre sql, con un buen mecanismo de almacenamiento en caché.

Otra opción es Torque, no estoy diciendo que sea mejor que cualquiera de las opciones mencionadas anteriormente, sino que es otra opción a tener en cuenta. Se está haciendo bastante viejo ahora, pero puede cumplir con algunos de sus requisitos.

Par

Cuando estaba buscando un reemplazo para Hibernate, me topé con Plataforma de acceso a DataNucleus , que es un ORM con licencia Apache2. No es solo ORM, ya que proporciona persistencia y recuperación de datos también en otras fuentes de datos que no sean RDBMS, como LDAP, DB4O y XML. No tengo ninguna experiencia de uso, pero parece interesante.

Considere romper su paradigma completamente con algo como tox . Si necesita clases Java, puede cargar el resultado XML en JDOM .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top