[
https://issues.apache.org/jira/browse/OPENJPA-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13617558#comment-13617558
]
Rakesh Jain commented on OPENJPA-2352:
--------------------------------------
Here is my scenario, I am putting in quite simplified form.
I have a bean called TestBean which contains 5 fields. Then I have a named
query which has implicit mapping of three fields of this bean. The other two
fields are not mapped in any way for this named query.
@NamedNativeQuery
(
name="testNamed",
query="select s.SERVER_ID as serverId, s.SERVER_NAME as serverName,
s.PORT_NUMBER as portNumber from server_table s ",
resultClass=TestBean.class
)
@Entity
public class TestBean
{
@Id
private int serverId;
private String serverName;
private int portNumber;
private String serverUrl;
private String serverLocation;
//geters/setters//
}
(In actual I will have complex query joining multiple tables).
Now, when I execute this named query using the following:
TypedQuery<TestBean> q = em.createNamedQuery(
"testNamed", TestBean.class);
List<TestBean> res = q.getResultList();
I get the results back fine. However, if you look at the logs (I have
jdbc.JDBC.level set to max debug), you see the following:
2013-03-29 10:49:49.266-07:00 [jcc][10150][10300][4.15.82] Invalid
parameter: Unknown column name SERVERLOCATION. ERRORCODE=-4460, SQLSTATE=null
2013-03-29 10:49:49.266-07:00 [jcc][10150][10300][4.15.82] Invalid
parameter: Unknown column name SERVERURL. ERRORCODE=-4460, SQLSTATE=null
Which is coming from that exception block in the ResultSetResult class, and it
is actually happening for every single row, so shows up as many times as the
number of records returned.
I would prefer to not go in that exception block at all, as otherwise it slows
down the getResultList() method is app servers, even though it works perfectly
fine in Tomcat or standalone Java.
Hope this helps.
> Retrieving column index for non existing field throws SQLException (ignored)
> causing slowness in application server
> -------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-2352
> URL: https://issues.apache.org/jira/browse/OPENJPA-2352
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 2.1.1
> Environment: All OS, I have tried with DB2 but problem may exist for
> all databases. WebSphere.
> Reporter: Rakesh Jain
> Labels: ResultSetResult,, exception, ignored, jdbc,
>
> When we have defined NamedNativeQuery and the query contains let's say 4
> columns. Now if we have a resultClass associated to that query which is
> simply a POJO having let's say five fields, four of which are mapped to the 4
> columns of the NamedNativeQuery, but the fifth one is not (after all it is
> POJO), the JPA tries to retrieve column index for that fifth field, and that
> throws SQL exception. The JPA code though ignores this exception, returning
> zero for column index. However, because an exception is throws, the
> application server in which this code is executing captures it and logs it in
> its corresponding logs. This causes the population of the result bean slow,
> and very slow if there are 4-5 or more fields unmapped.
> Here's the code fragment from
> org.apache.openjpa.jdbc.sql.ResultSetResult.java where this is happening.
> /**
> * Return the 1-based result set index for the given column or id, or a
> * non-positive number if the column is not contained in this result.
> */
> protected int findObject(Object obj, Joins joins)
> throws SQLException {
> try {
> String s1 = obj.toString();
> DBIdentifier sName = DBIdentifier.newColumn(obj.toString());
> return getResultSet().findColumn(_dict.convertSchemaCase(sName));
> } catch (SQLException se) {
> return 0;
> }
> }
> Moreover, this same method is called multiple times for each field,
> multiplying the problem.
> I would think a better approach would be to use ResultSetMetaData to retrieve
> all the column names and indexes, cache them and simply return from that
> cache in the findObject method.
> Is there any reason to keep it like this and not change to use metadata?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
