Hi All,
I have experience with Hibernate, EclipseLink and OpenJPA. Hibernate is
not an option, as you wrote in the chain below, although it is the
default JPA implementation.
Comparing EclipseLink and OpenJPA I vote for EclipseLink because of its
better performance, transaction handling and no computability issues.
I read some articles now about DataNucleus and as a conclusion I would
exclude it:
https://s3-eu-west-1.amazonaws.com/presentations2012/50_presentation.pdf
(2012))
https://www.researchgate.net/publication/313263324_Review_on_ORM_based_JPA_implementations
(2016)
https://pdfs.semanticscholar.org/5db6/f9d267a361debc5ddf7daf61cce82d7cdd5d.pdf
(2017)
"Very smart policies for collections."
"However, in terms of performance prospect DataNucleus is a dominant JPA
implementation but due to the *high complexity* and *lack of audience*,
it is *not a preferred API*. Another notable problem with DataNucleus
was the *lack**of* proper *documentation* support."
"With DataNucleus JPA we observed a significant, and unexpected,
*degradation of performance* and outofmemory exceptions, particularly
with heavy workloads.
*Memory leaks* with DataNucleusJPA"
Thanks,
Márti
On 2019. 07. 05. 18:10, Ed Cable wrote:
Are you able to add your thoughts on this discussion?
Ed
---------- Forwarded message ---------
From: *Awasum Yannick* <[email protected] <mailto:[email protected]>>
Date: Sun, Jun 30, 2019 at 11:48 PM
Subject: Re: [ Discussion ] ORM Migration
To: Dev <[email protected] <mailto:[email protected]>>
Hi Graham,
+1 EclipseLink as its supported by spring 4.x and latest spring
versions and compatible with Apache license. Our upgrade to Spring 5.x
or 6.x will be easier.
We dont want to build and maintain our own integration of OpenJPA with
Spring 5 or 6 in the future.
On Mon, Jul 1, 2019 at 7:40 AM Juhan Aasaru <[email protected]
<mailto:[email protected]>> wrote:
Hi!
Good job starting the discussion.
Based on your arguments I also see EclipseLink as the best solution.
I also found one more argument for using EclipseLink - it supports
multi-tenancy:
https://www.eclipse.org/eclipselink/documentation/2.7/solutions/multitenancy.htm#CHDBJCJA
Juhan
Kontakt Ebenezer Graham (<[email protected]
<mailto:[email protected]>>) kirjutas kuupäeval E, 1.
juuli 2019 kell 07:09:
Hello Devs,
I have started this thread to discuss the JPA implementation
to adopt as we work towards making Fineract CN Apache
compliant as well as to ensure that we are all aligned as a
community.
I am currently working on the migration to OpenJPA as my GSoC
project. However, a number of red flags as well and requests
from other community members has made it critical to start
this thread.
As most of you know, we can't use Hibernate as it's not
compliant therefore, it's essential that we migrate to an
equally good ORM.
*Our options:*
1. EclipseLink - EPL 1.0 & BSD
2. OpenJPA - Apache 2.0
3. DataNucleus - Apache 2.0
Not recommended
4. iBatic - Apache 2.0 (still functional but retired
https://ibatis.apache.org/)
5. TopLink - CDDL (category B license, and simply extend
EclipseLink)
I used the following criteria in the following order of priority.
1. License
2. Implementation's performance with respect to PostgreSQL
3. Support in Spring as well as ORM Documentation
4. Project Maturity
Right off the bat, I suggest the adoption of EclipseLink
<https://wiki.eclipse.org/EclipseLink> based on new insights
discovered, re-evaluation of our options, and compatibility
issues discovered whiles migrating to OpenJPA.
*Why EclipseLink? *
According to JPA Performance benchmark -
http://www.jpab.org/All/All/All.html EclipseLink is the Most
Efficient ORM (amongst our valid options) when persisting to
PostgreSQL and even outperforming Hibernate.
Performance Summary (with respect to Postgres)
EclipseLink - 10.5
Hibernate - 9.1
OpenJPA - 6.5
DataNucleus - 6.0
*Issues with OpenJPA.*
1. Spring dropped support back in 2017 and requests to resume
support was declined earlier this year
https://github.com/spring-projects/spring-framework/issues/20584.
There is no guarantee when it will be back in newer versions
of Spring. Spring 5 for instance no longer includes the
OpenJpaVendorAdaptor. Therefore, future upgrade of Fineract CN
will become an issue.
2. OpenJPA has been lagging behind - the stable version for
spring supports up to JDK 1.6 (although v3.0.0+ is working to
resolve this issue).
3. Bugs and compatibility issues with other libraries. I have
first-hand experience with it and it's not pleasant.
*Why not DataNucleus?*
It is not supported in Spring 4.x and its implementation will
require us to completely heavily refactor the JPA Layer in
Fineract CN on top of that, it's the slowest.
Looking forward to your recommendations and your own evaluations.
--
*Regards*
--
*Ed Cable*
President/CEO, Mifos Initiative
[email protected] <mailto:[email protected]> | Skype: edcable |
Mobile: +1.484.477.8649
*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
<http://facebook.com/mifos>//<http://www.twitter.com/mifos>
