So, if I understand you right, then the answer to my original question
("Why is there no need to close a Query?") is: Because a Query is not
1:1 related with a PreparedStatement. Is that right?
If that is true, how do I tell GlassFish / TopLink that the connection
might run out of Statement handles due to a admin-customized restriction?
Also I wonder if not beeing glued to a specific PreparedStatement isn't
a performance drawback. I mean, what happens internally if I do that:
Query q = em.createNamedQuery("myQuery");
for (int n = 1; n < 1000; n++)
q.setParameter(1, n);
In JDBC, the most performant way would be that a statement is prepared
one, then executed a lot of times in the loop.
So TopLink does NOT do that? Isn't that a big performance problem?
Also I do not understand WHY TopLink isn't do that: Since the loop is a
single transaction, there is no need to return the Connection into the pool.
Thanks
Markus
James Sutherland schrieb:
> JPA Query does not contain any open resources so does not require a close.
>
> Prepared statement caching in JEE is handled by the JEE DataSource. You can
> configure this in your JEE server DataSource config. TopLink, and
> EclipseLink (GFv3) also support prepared statement caching in JSE, see,
>
> http://forums.oracle.com/forums/thread.jspa?threadID=670453&tstart=0
>
> I'm not sure if this option was available in TopLink Essentials (GFv2). But
> TopLink Essentials does use prepared statements, so when used with a
> DataSource's statement caching the same benefit will be obtained.
>
> In TopLink the JPA Query generated SQL is also cached. So if you re-execute
> the same query it will not need to reparse the JPQL and generate the SQL.
> The best solution is to use named queries, so the SQL will always be cached.
> TopLink and EclipseLink also have a dynamic JPQL parse cache, that can avoid
> the JPQL parse cost even with dynamic JPA queries, but this was not
> available in TopLink Essentials.
>
>
>
> Markus KARG-3 wrote:
>
>> I am using JDBC for a long time, and I have been using other DBMS APIs for
>> far longer time. In almost any of those APIs I had the possibility to open
>> a "Prepared Statement", that will get reused internally by the driver (no
>> more need to parse the SQL again in a loop -- just the parameter values
>> will get send to the DBMS). This is a good performance tuning thing when
>> doing things in a loop, but one must take good care to close the statement
>> when done -- otherwise one might run out of statement handles soon (e. g.
>> in SQLAnywhere the admin can set a maximum limit of e. g. 10 open
>> statements per connection to find defective applications not closing
>> correctly the handles).
>>
>> Now since a few months I am using JPA, and I am wondering why there is
>> nothing like a Query.close() method. I am pretty sure that Oracle did it's
>> best to improve performance, so I expect that a query actually internally
>> is using a PreparedStatement instead of sending the same SQL string all
>> the time. But how to handle the out-of-handles problem?
>>
>> How does TopLink know that my admin is not allowing more than 10 open
>> handles?
>>
>> Or IS there some hidden Query.close() method that I just do not know?
>>
>> Thanks!
>> Markus
>>
>>
>
>
> -----
> ---
> http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
> http://www.eclipse.org/eclipselink/
> EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
> TopLink
> Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
> http://wiki.oracle.com/page/TopLink TopLink
> Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
> http://www.nabble.com/EclipseLink-f26430.html EclipseLink
> Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
>
--
http://www.xing.com/go/invita/58469