Hi Matthias,
Maybe changing the Batch Size :
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#Fetch_Size
And statement Caching :
http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_(ELUG)#How_to_Use_Parameterized_SQL_.28Parameter_Binding.29_and_Prepared_Statement_Caching_for_Optimization
Finally EclipseLink has a profiler.
Never used it, but sounds promising :
http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_(ELUG)#Measuring_EclipseLink_Performance_with_the_EclipseLink_Profiler
Please let me know if this helps or not.
regards.
Richard
On 5 March 2011 09:40, Richard Kolb <rjdkolb_at_gmail.com> wrote:
> Hi Matthias
>
> On 4 March 2011 16:49, Matthias Fraass <matthias.fraass_at_tricoder.net>wrote:
>
>> Am 04.03.2011 12:34, schrieb Richard Kolb:
>>
>> Another thing to remember is cache.
>>> You should proably have a second bunch of tests that do the queries
>>> twice. JPA will cache , so the second run should be much faster.
>>>
>>
>> I know but the use case is "batch processing" without any double entries.
>> So caching shouldn't happen anyway. I will change the example in that
>> respect.
>
>
> Ah, I see. Sorry I tried to get the sample going yesterday but for some
> reason it was not working and then I got distracted.
>
> Can you try the following and see if you get any performance gains:
> @Entity
> @Cache(shared=false)
> public class Customer {
> ...
> }
>
>
>
>
>>
>>
>> Don't forget to implement equals and hashCode on Customer to make JPA
>>> happy.
>>>
>>
>> I will do that!
>>
>
> Ok, but if you don't read your cache, I guess it won't add any performance.
>
> Maybe a bit off the topic, but have you tried other options to increase
> performance like @Asynchronous.
> It's really a magic part of Java EE 6.
>
> regards
> Richard
>
>