Indeed, I missed the Jonas piece :) No worries. On Thu, Nov 2, 2017 at 12:32 PM, Andy Gumbrecht <[email protected]> wrote:
> Yep, Steve, I'm sorry if I was short and I didn't look closely - Intention > is not to start an argument, just to focus on the JPA solution for > Prasenjit. > > Thanks, > > Andy. > > > On 02/11/17 16:16, Steve Goldsmith wrote: > >> 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. >> >> > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com > https://www.tomitribe.io > > -- Steven P. Goldsmith
