Thanks, I added bulk insert functionality which is straight jdbc to the database and performance is more normal now.
When I get some downtime I will pursue why JPA slows this down. It's only one table with 9 columns of type String and int. -sud [EMAIL PROTECTED] wrote: > sudhakar <[EMAIL PROTECTED]> writes: > > >> I'm using embedded derby in a Java SE application with OpenJPA. The >> applications parses a text file and creates JPA entity objects which it >> then turns around and persists in the embedded derby database using JPA. >> > > A general observation: The more fancy frameworks you put between your > code and the jdbc/SQL calls, the harder it will be to identify > performance problems. It's the price you pay for ease of > development. There is no free lunch I'm afraid. > > >> It starts of with inserting about 15 records per second and >> exponentially drops down to about one record every 25 seconds by the >> 400th record. I haven't tuned any of the derby parameters. >> > > You should definitely swing by the Derby web-site and make sure you > have done all the simple stuff. What you're describing sounds > unreasonable to me, but there is really no way to tell unless you say > how large your records are, and what the database schema looks like. > > >>> Before I >>> >> started getting into that I wanted to run this by here to find out if >> this is the out-of-box expected performance. It doesn't look right. The >> insert time per record increases exponentially. >> >> Can someone confirm that if something is awfully wrong here and how I >> can go about troubleshooting this. The text file is about 90000 records. >> So this exponential performance decrease would be completely >> unacceptable to the end-user. >> > > Sounds like something is wrong, yes. One thing you could try is to > turn on logging of SQL statments (derby.language.logStatementText see > the Tuning Guide), to see what actually happens during the insert. > >
