@Steve: question is not why JPA is slow but why a server is slower than another one (which leads to a misconfiguration). DBUnit/Hibernate-stateless etc can be good elsewhere but not sure it helps here :(
Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-11-02 16:16 GMT+01:00 Steve Goldsmith <sgj...@gmail.com>: > The issues is performance and if this is a one off batch insert then I'm > offering a solution. Alternatives are good and yes as I described before I > survived fine without all the JPA "features" with a production application > handling millions of transactions a day. This isn't theoretical and it > works in the real world. > > I'm not sure why you think there's no transactions. Caching is simple using > JCache (my app did this as well) which is agnostic to the persistence > layer. If you think DbUtils adds 256% over pure JDBC then you really have > not used it before or done any testing with it. Most JDBC wrappers add very > little latency as most of that is happening in the database. In essence you > are writing about the same lines of code as well. > > Maybe you didn't take a close look at the tests, but it throws out the > first run to account for any initialization/lazy optimizations in JPA. > Again, you may not find it useful, but DbUtils been proven to be much > faster in production systems than JPA and that's what really matters to me > at least. If you can provision 3x more VMs for the same task then knock > yourself out. > > Sorry to annoy you and hopefully you will find a JPA solution for Prasenjit.
