| Toplink 10.1.3.5.0 to EclipseLink 2.4 [message #1008795] |
Wed, 13 February 2013 16:33  |
Eclipse User |
|
|
|
Hi Guys,
We are conducting a project to migrate from Toplink version 10.1.3.5.0 to EclipseLink 2.4. We have about 300 tables all mapped using the old Toplink workbench which makes it impossible to use JPA at this moment.
We use external JDBC datasources and OC4J.
The migration of the session xmls, code and some other stuff went smoothly.
The problem started when we profiled the application using JMeter. It looks like the ReadAllQuery are taking longer in EclipseLink when compared with Toplink. But we are not sure if this is the only performance hit that we are having. We got to this conclusion when we activated the PerformanceMonitor in EclipseLink. I also back ported this class to Toplink trying to get the same measures. This was not very consistent.
Apart from packages we do not made any other changes in the code to support this migration.
All performance sites refer that EclipseLink is much (in some cases 15X) faster than Toplink. We tried to change the code with suggestions for these sites like making the queries read only or caching statements. This did not brought a boost in the system and so Toplink is currently faster than EclipseLink.
Attached you can find some important files.
- axncase.java is broken because the file os too big for upload but all our entities are constructed the same way.
- an entity object: Task.java
- session xml: axncase_de.xml
- ToplinkPersistenceManager and PersistenceJob: responsible for loading, inserting and updating data
Please provide any ideas on how to improve performance.
Thanks
|
|
|
|
| Re: Toplink 10.1.3.5.0 to EclipseLink 2.4 [message #1009813 is a reply to message #1009731] |
Fri, 15 February 2013 14:15  |
| Eclipse User |
|
|
|
This is a large project, probably too large to really go through in forum posts, so I would suggest going through support if you have not already where they can go over the conversion and mappings in detail and compare each setting in the two projects. Otherwise, I'd suggest breaking it down to a smaller test. Maybe a simple app that has one or two descriptors that you port over to EclipseLink. If it shows the same performance problem, then it is much easier to debug and find options and problems. Otherwise, then you know it is likely a conversion issue and can try narrowing down where in your app the problem might be.
For instance, do the problems occur with specific queries on specific classes, or is it every query, even simple find by primary key queries?
As for porting to JPA - EclipseLink allows using native mappings and sessions through JPA EntityManager API.
Best Regards,
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.03106 seconds
Home