Return-Path: X-Original-To: apmail-openjpa-dev-archive@www.apache.org Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F223DF0D9 for ; Fri, 29 Mar 2013 17:59:15 +0000 (UTC) Received: (qmail 36466 invoked by uid 500); 29 Mar 2013 17:59:15 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 36427 invoked by uid 500); 29 Mar 2013 17:59:15 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 36288 invoked by uid 99); 29 Mar 2013 17:59:15 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Mar 2013 17:59:15 +0000 Date: Fri, 29 Mar 2013 17:59:15 +0000 (UTC) From: "Rakesh Jain (JIRA)" To: dev@openjpa.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (OPENJPA-2352) Retrieving column index for non existing field throws SQLException (ignored) causing slowness in application server MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/OPENJPA-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13617563#comment-13617563 ] Rakesh Jain commented on OPENJPA-2352: -------------------------------------- And the specific method in ResultSetResult I am talking about is this: 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) { _dict.log.trace(se.getMessage()); return 0; } } > 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