Tim, Your last statements concern me... Was your commit performance due to conflicting processing between EclipseLink and OpenJPA? Or, was it due to OpenJPA itself? The performance concern with detachment processing (mentioned earlier) can be handled via properties. OpenJPA tends to optimize for re-attachment. But, if your entities are going to be GC'd anyway, then doing a more streamlined detachment would be the better approach. Any additional information you can provide on this environment would be great.
Thanks, Kevin On Tue, Feb 2, 2010 at 12:46 PM, Tim daley <[email protected]> wrote: > > I'm not doing a flush. > > > > I did: > > begin > > persist > > commit > > > > It is hanging in the commit. I'm using Eclipse, so I can't do a thread > dump. The properties were as simple as I could make them. > > > > I did notice that I was using Eclipse's EclipseLink with OpenJPA. I > thought mixing the two might be the problem so I stripped out the Open > JPA and upgraded to EclipseLink 1.1.3. Everything seems to be working > fine now. > > > > Tim Daley > Network Designer > Information Technology Group > Campus Crusade for Christ, Inc. > (407) 826-2911 Office > (407) 716-0284 Mobile > (407) 826-2968 Fax > [email protected] <mailto:[email protected]> > > > > > From: Simone Gianni [via OpenJPA] > [mailto:[email protected]<ml-node%[email protected]> > ] > Sent: Tuesday, February 02, 2010 1:06 PM > To: Tim Daley > Subject: Re: Extreme performance problems with OpenJPA commit > > > > Hi Tim, > are you closing the EntityManager after the flush? In that case, can you > > check if all this time is spent inside the clear() method of it? It > could be that the EntityManager is detaching all the instances, which > seems to be quite a time consuming operation (never seen 7 hours, but > never persisted 35.000 records at once, however 4 seconds for 200 > entities could expand to hours if it progresses non-linearly). > > In that case, I tried playing with the AutoDetach=false property a bit > to try to avoid OpenJPA to detach my entities, since in my case they are > > going to be garbage collected soon after, so there is no point in > detaching them. This somehow abbreviated that time. > > Hope this helps, > Simone > > Tim daley wrote: > > > > I'm loading a database with over 35,000 records into 100 tables. The > tables > > may be linked up to 6 levels deep. (Root, A, B, C, X, Y, Z, Root_A, > Root_B, > > Root_C, A_X, A_Y, B_X, B_Y, B_Z, A_C, B_C, C_Y, C_Z). There is a > single root > > that contains all the other records (A, B, C). The records contain > other > > structures (X, Y, Z) and some of the structures can contain other > > structures. > > > > The program builds all the data structure and then persists Root with > > everything specifying cascade-persist in the orm.xml. That all runs in > a > > couple of minutes. Then the commit is executed. A couple of minutes > later, I > > check the mysql log and all the inserts have occurred along with the > commit > > and quit. > > > > It then takes over 7 hours for the OpenJPA commit to return, even > though all > > records are actually committed and available. I'm running OpenJPA > 1.2.0, > > Java 1.6.0_10, MySQL 5.1. > > > > Can anyone advise me on how to speed this thing up? > > > > > > -- > Simone Gianni CEO Semeru s.r.l. Apache Committer > http://www.simonegianni.it/ > > > > > ________________________________ > > View message @ > http://n2.nabble.com/Extreme-performance-problems-with-OpenJPA-commit-tp > 4497009p4502457.html > To unsubscribe from Extreme performance problems with OpenJPA commit, > click here > < (link removed) > jY2kub3JnfDQ0OTcwMDl8MjA5NTM5NzAzMw==> . > > > > > > -- > View this message in context: > http://n2.nabble.com/Extreme-performance-problems-with-OpenJPA-commit-tp4497009p4502756.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. >
