Paul Clapham wrote:When my application loads an entity, it has to load about 15 other entities to support it. Each of these loads in a separate thread but not all at once, there's a network of dependencies which controls when the entities load. And behind it all is a JDBC connection pool which uses its own threads. It would be very hard to reduce that to something short and simple.
Ouch! And you think JPA is bad???
I inherited an app once kind of like that. The original author effectively loaded the entire database into memory at application start-up. Every time I ran a test is was 20 minutes or so to get to where I could do anything.
I got fed up, re-did it to do incremental fetch-on-demand with caching and dropped startup to 30 seconds.
When I design a JPA-based system, I deal with "working sets". Say, for example, the bus-route system I once worked on. Entity types included physical buses, logical buses, routes, stops, schedules and so forth. If I want to work on a route,, I'd fetch the route record and the collection of stop records and detach them from the database, returning them as a subset data graph of the whole. Everything I needed and nothing I did not. I'd do my dirty work, then pass the graph back to the business persistence level, which would wrap the update process in a transaction and invoke the lower-level DAOs to handle pushing the updated components back to the database. I didn't have to keep redundant stuff hanging around, because in most cases, JPA's own internal caching kept popular items in memory without me having to track them manually. This is especially important for systems that want to keep session-scope memory usage minimal or non-existend (ReST).
For really large jobs ORMs have been clocked at double the throughput of raw JDBC because even though JPA is built on JDBC, it can work smarter, not harder. Plus most of the grunt code is pree-debugged and Someone Else's Problem.
To me JDBC is like assembly language. In my mainframe days, we had virtually no choice but to use assembly language. C wasn't available and the stock high-level languages demanded a runtime support infrastructure that simply could not work in OS-internal code. We hated it, and I saw more bubble-sorts and short-but-ugly solutions than I want to think about. We agonised over every microsecond and were almost never able to re-use code. Virtually no support libraties.
I can still do assembly on about 5 different hardware platforms. I almost never do, because in most cases it's more efficient both in my own and CPU resources to work with higher-level mechanisms.
So I bet I could snippet my database code without much trouble,
1
