dev@glassfish.java.net

Re: Optimizing the CORBA...

From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Date: Wed, 19 Jul 2006 12:25:43 -0700

Kenneth Saks wrote:
>>
>>
>>>
>>>
>>> Dyego Souza Dantas Leal escreveu:
>>>
>>>> Hello GlassFish guys !!!
>>>>
>>>> GlassFishVersion : v2 b08
>>>>
>>>>
>>>> I have a problem... i write a JEE 5 Application with SessionBeans
>>>> and client Swing...
>>>>
>>>> i run this query in my sessionbean
>>>>
>>>>
>>>> em.createQuery("select m from MyEntity m").getResultList();
>>>>
>>>> This query return's 292 entitys in 95 ms (good time...)
>>>>
>>>> BUT , in the client...(swing) this query returns in 795ms ....
>>>>
>>>> 700ms for serialization ? is a bad time...
>>>>
>>>> exists way to optimize it ?
>>>>
>>>>
>
>
> The serialized object graph of the entire set of entity query results
> returned from the remote ejb call is likely much larger than the raw
> data sent from the database to the server during query execution. That
> could certainly account for the difference. Tuning the RMI-IIOP path
> is one approach but the bottom line is that sending a large number of
> serialized objects over a remote call can be expensive. You might want
> to investigate ways to redesign your Swing client to request a smaller
> amount of data at a time, either by requesting a subset of the query
> results(e.g. Query.setFirstResult/setMaxResults) or by only returning a
> portion of the data in each entity. Persistence team, any suggestions
> here?

It might very well be the case that the actual objects sent to the client
represent more than just MyEntity if there are any relationships to any
other entities that had been set in memory. TopLink implementation uses
global (one per EMF) cache and any instance returned from the query is
actually substituted by the cached one, if it's already known to the
system. If this is the case, the serialized-deserialized object graph
can be quite large. If not, the problem is somewhere else...


thanks,
-marina

>
>
>>
>>
>> Certainly we would expect some remote overhead, but this seems excessive.
>>
>> Ken.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>