[2018 oracle code one] mastering jpa performance

Main menu:

Topics

Recent Posts

Feeds

RSS Feed RSS - Posts

October 2018
M T W T F S S
« Sep   Nov »
1234567
891011121314
15161718192021
22232425262728
293031  

Past Posts

Java/Java EE

JDBC

Other

[2018 oracle code one] mastering jpa performance

October 25th, 2018 by Jeanne Boyarsky

Mastering JPA Performance
Speaker: Thomas Broll
@speakjava

For more blog posts, see The Oracle Code One table of contents


Problem

  • Users complain
  • With microservices more important beause more calls

General

  • Apache lang has ImmutableTriple class

Techniques

  • Monior – number sql statemtenrs, cpu, i/o
  • hibernate.show_sql = true
  • run jstack while transaction running to see where stuck
  • Check JDBC driver batch size

Create – Performance improvements

Scenario: writing large amounts of data

  • Use table generator (vs sequence generator) where gt batch of ids so not a roud trip to get it each time. Even better to use external UUID generator
  • JPA only supports one open batch. But goes to database if do a query or persist a different entity. So faster if persist by entity

Read – Performance improvements

  • 1+N problem. One statement in code. Executes more statement to get relationships. All, XToOne are eagerly loaded
  • Can provide hints to eagerly or lazy load
  • fetch query to get data actually needed – can put it in the JQL query
  • Can get Hibernate statistics for number of queries/loads/fetches
  • Cal setFirstResult() and setMaxResults() on query object

Update – Performance improvements

  • Auto flushes are caused by transaction commit, insert/delete, query or explicitly flush()
  • Performance cost due to dirty checks and actual updates. Cost also depends on size of persistence context
  • Call getReference() to get empty proxy. This allows saving without changing in database?

Delete – Performance improvements

  • Remove() requires persistent entities, requires loading reference
  • Delete by query could be more efficient

Cloud

  • Two orders of maginude worse when database on different continent.
  • 35 minutes to do 5 second run when database on a different continent

My take: It’s been a while since I look at this topic. It was a good mix of review and things I never knew. Not having a physical network between the machine and database really hanges the numbers. It would have been nice to use a cloud database to get those numbers [scratch that; he did at the very end. I would have liked to see it earlier]

Write a comment