CODEWITHSUNDEEP
javaperformancehibernatejpah2
user1050755
user1050755

Reputation: 11691

Is the default Hibernate (5.2.5) session-level cache killing performance?

I'm not sure if this observed effect is due to Hibernate's session cache, but it looks to me that way. I'm currently running test units against a H2 (v1.4.x/MVCC) database backend stored on SSD. I'm inserting 10k+ rows and the performance with 'pure' JPA is very poor and I have one CPU running at max speed doing inserts of 'regular' rows at a speed of 200-300 per second. Now the interesting part: when I wrap each insert statement ('em.persist(...)') into a separate transaction and 'detach' the persisted object from the entity manager immediately after the commit, speed goes up ten-fold. Somehow Hibernate seems to forget dumping persisted objects and accumulates them without any detectable limit.

Why is default performance so crappy? Does really nobody care about that or what am I getting wrong here?

For some reason, Hibernate complains about JDBC connections not being in autocommit mode initially. Is this related?

Upvotes: 0

Views: 152

Answers (1)

JB Nizet
JB Nizet

Reputation: 692081

Hibernate seems to forget dumping persisted objects

No, it doesn't forget anything. It keeps them managed in the session on purpose, because not doing that would violate its own contract: you're supposed to be able to modify the managed object after it has been persisted, and have these changes saved in the database. JPA would be quite useless if it returned detached objects.

That shouldn't prevent you from explicitly detaching them if you need to, as the documentation suggests doing when you need to insert a massive number of elements (which is not the use-case Hibernate/JPA has been designed for).

Upvotes: 4

Related Questions