An interesting read, showing that Hibernate can quickly get to its limits when it comes to querying 50k records – a relatively small number of records for a sophisticated database:
http://koenserneels.blogspot.ch/2013/03/bulk-fetching-with-hibernate.html
Of course, Hibernate can generally deal with such situations, but you have to start tuning Hibernate, digging into its more advanced features. Makes one think whether second-level caching, flushing, evicting, and all that stuff should really be the default behaviour…?
March 8th, 2013 at 14:07
Hi Lukas.
Couldn’t agree more. All this second-level caching, flushing, evicting nonsense is to paper-over philosophical mismatch between relational databases and the Hibernate “way”.
You can read more on “how OneWebSQL differs from Hibernate”. It’s OneWebSQL specific, but you can get an insight on how Hibernate first breaks something that works (relational database model) and then tries to “solve” it by throwing more broken solutions at it.
March 8th, 2013 at 14:15
Hi Tomasz,
Trying to get some more hits from my blog?
How’s sales doing for OneWebSQL?
March 15th, 2013 at 13:52
Hi Lukas.
Of course I do
Thanks for asking, we already have paying clients
March 8th, 2013 at 19:02
Hibernate sucks in performances. All three projects I’ve seen using it were screwed by it and design decision. I was researching alternatives, that’s how I found this blog. We have our own version of CRUD framework (simple ORM), which is there to bring good performances, however, my company haven’t managed to find clients for it, apart that we are using to power few of our products (web).
March 9th, 2013 at 12:10
Well, it doesn’t suck per se. It sucks “per default”. Once you know how to tweak it, it’s a pretty good framework, but you seem to have to know a lot, first…