¿Qué proveedor persistente de EJB 3 debo utilizar?

Question

Estoy usando EJB 3 en un proyecto J2EE bastante grande; de ​​forma predeterminada, Netbeans establece el proveedor persistente para los beans de entidad en TopLink.Existe la opción de cambiar el proveedor a uno de los siguientes o incluso agregar una nueva biblioteca de persistencia:

• Hibernar
• KODO
• AbiertoJPA

¿Qué proveedor de persistencia prefieres utilizar?¿Cuáles son los beneficios de utilizar otro proveedor?

Si bien TopLink parece ser bueno, no puedo encontrar mucha documentación buena sobre cómo controlar el almacenamiento en caché, etc.Cualquier ayuda sería muy apreciada.

Answer 1

Sólo hay dos proveedores JPA que consideraría usar:

Si desea ceñirse al JPA estándar, usaría EclipseLink.Mientras que Toplink Essentials es la implementación de referencia de JPA 1.0, EclipseLink básicamente heredó el código de TopLink Essentials y será la implementación de referencia de JPA 2.0 (y se incluirá con Glassfish V3 cuando se envíe;esperado alrededor de JavaOne en mayo de 2009).TopLink Essentials era una versión algo dañada del producto comercial TopLink de Oracle, pero EclipseLink básicamente tiene todas las características que tiene TopLink.

La otra opción es obviamente Hibernar.Es ampliamente utilizado y maduro, pero no está libre de problemas por lo que he visto.Por ejemplo, la última vez que vi, Hibernate tiene problemas con una entidad que tiene múltiples relaciones entusiastas de uno a muchos.No sé si Hibernate tiene un equivalente a la sugerencia de consulta por lotes de EclipseLink, pero es una característica increíblemente útil para lidiar con este tipo de problemas.

Hibernate, por supuesto, también es compatible con JPA estándar.La mayor ventaja de Hibernate es que si tiene preguntas sobre cómo funciona, es probable que una búsqueda en Google encuentre una respuesta.

Sinceramente, no consideraría nada más que los dos proveedores anteriores.

Answer 2

Recomiendo encarecidamente Hibernate por las siguientes razones:

• La capa de persistencia de código abierto más utilizada y respetada en el mundo Java;enorme comunidad activa y mucho uso en aplicaciones de misión crítica de gran volumen.
• No se vincula en absoluto a J2EE ni a un proveedor específico si desea tomar una ruta diferente con el resto de su aplicación, como Spring, etc., ya que Hibernate seguirá funcionando bien.

Answer 3

He encontrado que Hibernate está bastante bien documentado y bien soportado por las diversas tecnologías de almacenamiento en caché.También lo he usado bastante más que los demás en contextos que no son JPA, por lo que tal vez estoy un poco predispuesto a favor de él por eso.

Los pocos pequeños proyectos de juguete que probé con TopLink Essentials también funcionaron bastante bien, pero nunca me metí en el almacenamiento en caché ni en nada que requiriera documentación específica del proveedor.En general, creo que hay menos apoyo de la comunidad para esto, lo cual es parte de la razón por la que termino usando Hibernate.

Answer 4

Yo uso Hibernar.Es muy maduro y funciona muy bien.Personalmente no he usado ninguno de los otros, pero sí sé que Hibernate es uno de los proveedores JPA con más funciones que existen.Además, debido a que tanta gente lo está usando, casi todos los problemas que he tenido con él, puedo encontrar rápidamente una solución con un poco de búsqueda en Google.

Answer 5

Recientemente trabajé en una gran aplicación empresarial creada con el marco Kodo JPA.Los SQL producidos por Kodo generalmente no eran muy escalables con una gran cantidad de datos.En mi opinión, produjo demasiadas consultas con combinaciones externas.Teniendo en cuenta cuántas asignaciones tuvimos que cambiar al intentar escalar Kodo, no recomendaría usarlo para una aplicación empresarial grande.Incluso los representantes de Oracle con los que hablamos están tratando de alejar a los clientes de kodo y pasarlos a TopLink.Oracle puede eliminar kodo en el futuro.

Answer 6

Núcleo de datos http://www.datanucleus.org También es un proveedor JPA totalmente compatible, con JPA1 y algunas características preliminares de JPA2.