You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Rick Curtis (Created) (JIRA)" <ji...@apache.org> on 2011/11/02 19:33:32 UTC
[jira] [Created] (OPENJPA-2068) Improve performance of
java.util.Calendar fields
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
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
[jira] [Updated] (OPENJPA-2068) Improve performance of
java.util.Calendar fields
Posted by "Rick Curtis (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Curtis updated OPENJPA-2068:
---------------------------------
Attachment: OPENJPA-2068.patch
I'm attaching a patch with a bulk of the changes. Obviously this isn't complete, but I want to get something out here.
> 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
> 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
[jira] [Resolved] (OPENJPA-2068) Improve performance of
java.util.Calendar fields
Posted by "Rick Curtis (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Curtis resolved OPENJPA-2068.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.2.0
> 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
[jira] [Resolved] (OPENJPA-2068) Improve performance of
java.util.Calendar fields
Posted by "Rick Curtis (Resolved) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (OPENJPA-2068) Improve performance of
java.util.Calendar fields
Posted by "Rick Curtis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166293#comment-13166293 ]
Rick Curtis commented on OPENJPA-2068:
--------------------------------------
The code I committed doesn't have the quirk where you'll get a proxied instance when you issue a query where you only are selecting a Calendar field. Also, this behavior isn't configurable as it is transparent.
> 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
[jira] [Closed] (OPENJPA-2068) Improve performance of
java.util.Calendar fields
Posted by "Albert Lee (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Albert Lee closed OPENJPA-2068.
-------------------------------
Close issue in preparation for 2.2.0 release.
> 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
[jira] [Commented] (OPENJPA-2068) Improve performance of
java.util.Calendar fields
Posted by "Rick Curtis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189160#comment-13189160 ]
Rick Curtis commented on OPENJPA-2068:
--------------------------------------
The bug we hit resulted in the following exception:
<openjpa-2.2.0-SNAPSHOT-r422266:1232415 nonfatal user error> org.apache.openjpa.persistence.InvalidStateException: This container was loaded in large result set field "[x].entities.LrsEntityA.entitybs", but has been removed from its owning field. Therefore, it can no longer be used.
at org.apache.openjpa.jdbc.meta.strats.LRSProxyCollection.assertOwner(LRSProxyCollection.java:167)
at org.apache.openjpa.jdbc.meta.strats.LRSProxyCollection.itr(LRSProxyCollection.java:127)
at org.apache.openjpa.util.AbstractLRSProxyCollection.iterator(AbstractLRSProxyCollection.java:251)
at org.apache.openjpa.util.ProxyCollections.addAll(ProxyCollections.java:142)
at org.apache.openjpa.util.java$util$ArrayList$proxy.addAll(Unknown Source)
at org.apache.openjpa.kernel.SingleFieldManager.proxy(SingleFieldManager.java:112)
at org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2602)
at org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy.load(StoreCollectionFieldStrategy.java:524)
at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:934)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:664)
at com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.load(WsJpaJDBCStoreManager.java:130)
at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:117)
at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78)
at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:3072)
at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:3149)
at org.apache.openjpa.kernel.StateManagerImpl.beforeAccessField(StateManagerImpl.java:1613)
at org.apache.openjpa.kernel.StateManagerImpl.accessingField(StateManagerImpl.java:1598)
at [x].entities.LrsEntityA.pcGetentitybs(LrsEntityA.java)
at [x].entities.LrsEntityA.getEntitybs(LrsEntityA.java:49)
> 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
[jira] [Reopened] (OPENJPA-2068) Improve performance of
java.util.Calendar fields
Posted by "Rick Curtis (Reopened) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Curtis reopened OPENJPA-2068:
----------------------------------
Reopening this issue as it introduced a new bug that was uncovered through some internal testing.
> 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