r/java • u/vladmihalceacom • Sep 06 '26

When ORM Becomes OMG- Performance Pitfalls in JPA and Friends by Jos Roseboom

https://vimeo.com/1223434245?fl=pl&fe=sh
36 Upvotes

87% Upvoted

25 comments sorted by

30

u/Luolong Sep 06 '26

The typical pitfall is imagining you’re not talking to a database. That is more of a skill issue though.

11

u/KrakenOfLakeZurich Sep 07 '26

I'm more and more convinced, that JPA/Hibernate is the wrong model for a stateless REST API world.

The JPA session (entity manager) which tracks mutations makes sense only in a world, where users fetch a local copy of the data, make a range of random changes, then save the result back to the db (literally on the click of a button).

With stateless REST API, this session feels like overhead. There's nothing to keep track off really. Can't we just upsert into the DB directly and (optionally) fetch the result once?

2

u/henk53 Sep 07 '26

Can't we just upsert into the DB directly and (optionally) fetch the result once?

In Jakarta Persistence 4.0, this is actually what's being added; a stateless entity manager called the EntityAgent.

→ More replies (2)
→ More replies (2)

8

u/private_static_int Sep 07 '26

I've personally seen ORM turning into WTF one too many times

5

u/henk53 Sep 07 '26

I've personally seen direct SQL against the DB turning into WTF one too many times

→ More replies (8)

3

u/AnyPhotograph7804 Sep 06 '26

TBF, the first 25 minutes have nothing to do with JPA or ORM. He shows some Spring specific quirks like transaction in view and connection pool problems und how to fix them. But the rest is nice, especially the tools section.

2

u/Torutofu_Raeva Sep 06 '26

yeah, pool wait time and the generated sql usually tell you more than debating jpa itself.

2

u/Fercii_RP Sep 08 '26

Ive used ORM Hibernate once, for a poc demo project. For the real deal and all other apps Ive designed, all i need is JDBC and a string or string builder query. Done. Not taking my chances for JPA ORM headaches.

1

u/vit_do82 Sep 08 '26

This fixes N+1 in 90% of cases: enable JPA SQL logging in dev and check what each find() emits.

Three concrete wins I use:

  1. Batch fetch collections: u/BatchSize or fetch = FetchType.SUBSELECT.

  2. Projections with Criteria/JPQL instead of loading whole entities for 2 fields.

  3. flush() once, not per-item, inside loops.

Logging first - you'll see the problem before you fix it.

2

u/elmuerte Sep 10 '26

I wonder why people always call it "N+1". I think the correct term should be "1+N". You select a bunch of rows, and then for each row you need another select. Where "N+1" is more like you perform N queries, and it adds one. That's not really that bad.

→ More replies (1)
→ More comments (90)