From: Steve E. (JIRA) <no...@at...> - 2006-05-22 21:08:15
|
collection batch fetching ------------------------- Key: HHH-1775 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775 Project: Hibernate3 Type: Improvement Components: core Reporter: Steve Ebersole Assigned to: Steve Ebersole Priority: Minor Fix For: 3.2.0 I have code local on my box to support "peeking" into the second level cache when determining whether to add a particular entity/collection key to a batch load request. If the given key is contained in the second level cache, then do not batch fetch the entity/collection as it will be initialized from second level cache on access. However, there are still large inefficiencies when performing this for collections; the biggest of which currently is the fact that we retreive a IdentityMap.entrySet for each and ever call to determine a collectiomn fetch batch. For performance reasons, we should align this with how entity batches are handled where the entity keys considered to be "batch loadable" are tracked seperately on the BatchFetchQueue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: The S. (JIRA) <no...@at...> - 2006-06-21 15:29:32
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775?page=comments#action_23371 ] The Shadow commented on HHH-1775: --------------------------------- testing, please ignore > collection batch fetching > ------------------------- > > Key: HHH-1775 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.0 > > > I have code local on my box to support "peeking" into the second level cache when determining whether to add a particular entity/collection key to a batch load request. If the given key is contained in the second level cache, then do not batch fetch the entity/collection as it will be initialized from second level cache on access. > However, there are still large inefficiencies when performing this for collections; the biggest of which currently is the fact that we retreive a IdentityMap.entrySet for each and ever call to determine a collectiomn fetch batch. For performance reasons, we should align this with how entity batches are handled where the entity keys considered to be "batch loadable" are tracked seperately on the BatchFetchQueue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Christian B. (JIRA) <no...@at...> - 2006-06-21 15:42:33
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775?page=all ] Christian Bauer updated HHH-1775: --------------------------------- Comment: was deleted > collection batch fetching > ------------------------- > > Key: HHH-1775 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.0 > > > I have code local on my box to support "peeking" into the second level cache when determining whether to add a particular entity/collection key to a batch load request. If the given key is contained in the second level cache, then do not batch fetch the entity/collection as it will be initialized from second level cache on access. > However, there are still large inefficiencies when performing this for collections; the biggest of which currently is the fact that we retreive a IdentityMap.entrySet for each and ever call to determine a collectiomn fetch batch. For performance reasons, we should align this with how entity batches are handled where the entity keys considered to be "batch loadable" are tracked seperately on the BatchFetchQueue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Steve E. (JIRA) <no...@at...> - 2006-06-28 16:44:17
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775?page=all ] Steve Ebersole updated HHH-1775: -------------------------------- Fix Version: 3.2.1 (was: 3.2.0.cr3) > collection batch fetching > ------------------------- > > Key: HHH-1775 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.1 > > > I have code local on my box to support "peeking" into the second level cache when determining whether to add a particular entity/collection key to a batch load request. If the given key is contained in the second level cache, then do not batch fetch the entity/collection as it will be initialized from second level cache on access. > However, there are still large inefficiencies when performing this for collections; the biggest of which currently is the fact that we retreive a IdentityMap.entrySet for each and ever call to determine a collectiomn fetch batch. For performance reasons, we should align this with how entity batches are handled where the entity keys considered to be "batch loadable" are tracked seperately on the BatchFetchQueue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Sergey V. (JIRA) <no...@at...> - 2006-06-28 17:21:46
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775?page=comments#action_23461 ] Sergey Vladimirov commented on HHH-1775: ---------------------------------------- Steve, entrySet calls can be replaced by entryArray calls, as suggested in patch for HHH-1691, for example. Need only one call for building whole array. Another possible solution is to wrap IdentityMap to IdentityMapEntry set/list. One can create set which will updated sync. with IdentityMap. Let me know if it is intersting :) Anyway, +1 for any perfomance-related improvments. > collection batch fetching > ------------------------- > > Key: HHH-1775 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.1 > > > I have code local on my box to support "peeking" into the second level cache when determining whether to add a particular entity/collection key to a batch load request. If the given key is contained in the second level cache, then do not batch fetch the entity/collection as it will be initialized from second level cache on access. > However, there are still large inefficiencies when performing this for collections; the biggest of which currently is the fact that we retreive a IdentityMap.entrySet for each and ever call to determine a collectiomn fetch batch. For performance reasons, we should align this with how entity batches are handled where the entity keys considered to be "batch loadable" are tracked seperately on the BatchFetchQueue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |