Original author(s) Development status Active Operating system | Developer(s) Asım Arslan Written in Java | |
Stable release 2.0.1.1 / June 1, 2013 (2013-06-01) | ||
Batoo JPA is an implementation of Java Persistence API version 1.0 and 2.0. It is created as a response to the assumption that the current JPA implementations are quite heavy implementations that require large CPU resources during execution therefore makes it expensive or impossible to run Java applications on top JPA technology in large scale or mobile and embedded systems.
Contents
Background
Ceylan, the founder of Batoo JPA, was recently assigned tasks to solve performance problems in large projects mainly telecom and social networking applications. While attaining performance improvements in various proprietary applications, he adopted a large knowledge of performance on top of earlier experience. During these works, he also discovered that Hibernate the leading JPA provider (and also others), while providing fast develop to market ability, are simply also extremely performance demanding, increasing the production costs of the applications. He has seen applications running on gigantic hardware but still under-performing according to project needs. Amazed with the opportunity and wide use of JPA technology in the Java ecosystem, he then developed the prototype which gave 1 / 50 operating costs at the JPA level. The main development of Batoo JPA has been finished as of August 2012 and project has been released as of October 2012.
License
Batoo JPA is provided as open source project with LGPL licence.
Benchmark
Primary goal of Batoo JPA is to provide community with a lightweight, robust and fast implementation of JPA. To attain this, as part of Batoo JPA, a benchmark project is developed to benchmark Batoo JPA against other JPA implementation after every development iteration.
Based on this specific benchmark of the first released version of Batoo JPA, Batoo JPA compares to leading JPA implementation as below:
Those numbers have been criticized as being only focused on cpu utilization of the application server, while the real load and most time spent actually happens on the database server.