Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Date: Thu, 19 Jan 2012 15:36:40 +0000 (UTC)
From: "Rick Curtis (Resolved) (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Message-ID: 
 <985812983.56369.1326987400610.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2020098196.51908.1320258812343.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (OPENJPA-2068) Improve performance of
 java.util.Calendar fields
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/OPENJPA-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Curtis resolved OPENJPA-2068.
----------------------------------

    Resolution: Fixed

Committed testcase and code fix to trunk.

Resolving issue.
                
> Improve performance of java.util.Calendar fields
> ------------------------------------------------
>
>                 Key: OPENJPA-2068
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2068
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: jdbc
>    Affects Versions: 2.2.0
>            Reporter: Rick Curtis
>            Assignee: Rick Curtis
>             Fix For: 2.2.0
>
>         Attachments: OPENJPA-2068.patch
>
>
> While doing some performance testing, I've found that we could improve the performance of loading Entities that have java.util.Calendar fields. When loading the data into a Calendar field, we actually create two Calendar instances per field. Normally creating an extra instance wouldn't be that big of a deal, but since creating a Calendar is very expensive I would like to remove creation of the extra instance.
> The call flow is something like this:
> - em.find(...) // find an Entity which has a calendar field
> ... execute query, processing result set...
> - DBDictionary.getCalendar(ResultSet,...) // Here we pull a Timestamp out of the result set, and create an unproxied Calendar instance.
> ...
> // now while trying to store the Calendar into the Entity instance, we find that this type needs to be proxied. 
> SingleFieldManager.proxy(...) // Here we create the second Calendar instance, which is a proxied calendar
> I'd like to add a configuration property to DBDictionary that tells the runtime to always create proxied calendar instances. This would remove the creation of the initial un-proxied instance. For a large majority of application which use Calendars this would help. 
> As always, there is a catch to this approach. If you were to execute a query such as : em.createQuery("SELECT c.myCal FROM CalendarEntity c where c.id=:id", MyCalendar.class), you would get back a proxied instance. This shouldn't be that big of a deal... but still a bit of a quirk.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira