Alternative to JPA Implementation

Asked

Viewed 632 times

4

I am using JPA in a project, with the Hibernate implementation, still using Java 7.

And constantly Permgen runs out of space. I know it’s because of Hibernate, how new I am in this java technology. Someone knows indicate some less heavy implementation for JPA. I went to use Eclipselink was worse because I didn’t even deploy it.

I didn’t want to increase Permgen, I wanted a solution and not a palliative.

Already in Java 8 I’m not with this problem because there is no more space, was replaced by Metaspace, even so the application grows too.

Any hint?

java-ee orm

2 answers

4

I would say that your problem is more related to how you use JPA than JPA as a problem.

Eclipselink, Hibernate, Openjpa or Batoo will continue giving problem. With Java8 you will burst the memory the same way, the diffraction is the type of error that will appear.

This error appears with JPA when you bring too much data to memory. This error would also appear with JDBC very easily.

Some solutions to this problem is:

  1. Paged search - Instead of simply bringing 15,000 database results, bring only what will be displayed to the user
  2. Avoid annotated relationships with @EAGER. When announcing relationships with @EAGER you will be bringing unnecessary information and with it will fill the memory unnecessarily
  3. Make specific queries with JPQL. If you need to bring relationship data, create a JPQL for this, for example: select c from Cachorro c join on c.pessoas p where c.id = 33 Note that with this I limit the data that will be brought.
  4. Bring your objects as Detached. You optimize the use of JPA if it is just a read only query of information. With EJB use transaction NOT_SUPPORTED, with Spring @Transactional(readonly = true) and if manual transaction does not entityManager.getTransaction().begin().

Now, if you want to leave JPA you could take a look at Mybatis (http://www.mybatis.org/) or Querydsl (http://www.querydsl.com/)

  • But this Permgen crash happened right after the deploy, with 10 records in the bank, I know my Permgen was small anyway. However, I wanted a solution so that the data would not increase in this way. As for the actualization of these API I liked the Querydsl, the iBatis I used, but wanted a ORM(automatic).

  • @uaiHerbert, Java8 no longer has Permgen, is now Metaspace, and the default size is the limit available on your computer, I know that one day the memory will burst.

  • 1

    If you have available all the machine memory, in the case of Java8, I do not understand what the problem is of increasing Permgen. If with 10 objects memory already flies I don’t think any other framework would solve your problem. If you use pure JDBC, maybe not with 10, but memory will burst in the same way.

  • If you search for objects like Detached the memory usage will decrease, but still, it will not solve your problem having a server with such limited memory.

  • No, the memory overflow is not related to the application data, for example: millions of records I search from the database, these millions of objects will be removed by GC, the problem is that some API carry a lot of class from your lib, and these classes not registered in Permgem(extinct No 8). But, is not pq was extinguished in version 8, which I must be reassured, as it has many applications I need from previous versions(in case I need).

  • This end of Permgen I see as a 'makeup'. Even in Java8 you can also limit the size of the memory used, which by default is not enabled. I see that good practice the correct is to limit the memory size and not leave open for infinite use.

  • I doubt very much that your application carries millions of records without JPA and with only 10 records already happens the memory overflow. I believe that there is some misuse there.

  • Of course, that’s why I was looking for an alternative to Hibernate/JPA, because I don’t want to keep increasing my Permgen just so I can use Hibernate. I know this mémoria: 1º is not associated with the application data. 2º GC does not have access to collect any data that has been logged, nor even clear the loaded classes (it makes no sense to clear the loaded classes). 3º Hibernate and Eclipselink loads many classes.

  • Any ORM mapping will load classes into memory. Unless they bravely want to implement their own reflection, which is something I’ve heard about.

Show 4 more comments

2


the Staff of Lipstick claims that it is a fast and lightweight implementation. The source is open and you can test Benchmark at https://github.com/BatooOrg/BatooJPABenchmark.

In this post the author says that Batto is 15 times faster than Hibernate.

I think it’s worth a try.

Another option is to abandon JPA and use something simpler like Pattern DAO (Data Access Object) and in this case take a look at this implementation Ormlite. Sometimes your data model is complex enough and a DAO Pattern does not solve.

Browser other questions tagged java-ee orm

You are not signed in. Login or sign up in order to post.