[
https://issues.apache.org/jira/browse/OPENJPA-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614074#comment-13614074
]
Rick Curtis commented on OPENJPA-2352:
--------------------------------------
Can you post a small unit test showing this behavior?
If my testing, it appears that if the resultClass is a POJO (with NO JPA
mapping data), we do not run through this exception path.
> 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
