[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2277?page=all ] Steve Ebersole updated HHH-2277: -------------------------------- Fix Version: 3.2.2 Assign To: Steve Ebersole -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2277?page=c... ] Emmanuel Bernard commented on HHH-2277: --------------------------------------- Damn that must have been my Hibernate3 trunk amnesia week, sorry. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2277?page=c... ] Steve Ebersole commented on HHH-2277: ------------------------------------- The distinction between UniqueEntityLoader#load and other accesses to Loader#doQueryAndInitializeNonLazyCollections is perhaps anecdotal. The difference in the tests being the order in which the underlying persisters are processed (and thus the order in which the keys are read from the result set). -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2277?page=all ] Steve Ebersole updated HHH-2277: -------------------------------- Fix Version: (was: 3.2.3) 3.3 After thinking this through some more, I think the real solution is to wait until we have actual ComponentPersisters (or whatever they are called) and have components taking join in two-phase loading. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2277?page=c... ] Steve Ebersole commented on HHH-2277: ------------------------------------- Actually 2-phase load will not even help here. 2-phase load still has an implied contract that the ids all be resolved up front. And that is unfortunately the issue here. In other words, given: {noformat} Customer( long id ) Order( PK id( Customer customer, long orderNumber ) ) {noformat} The algorithm performed by Loader to read a row is # read all keys from the result set # read all values from the result set In the problematic case, this means that it tries to: # read the Order key from the result set # read the Customer key from the result set # read the Order values from the result set (using 2-phase load) # read the Customer values from the result set (using 2-phase load) (the order of Customer/Order here is irrelevant) So in step (1) it is unable to resolve the Order key fully because Customer has not yet been processed. Since it does not "see" the Customer it attempts to load it, which forces the Loader to basically just get called again (hence the infinite loop). The other issue here with *just* having a 2-phase load for components is that the order in which these get processed from the result set now becomes important. The only option I see is some form of "order aware" solution, where the Loader knows about the relationship between the persisters it is processing (it does sorta/kinda in that the order of the persisters returned by org.hibernate.loader.Loader#getEntityPersisters is semi-important). Really what needs to happen here specifically is that Customer needs to be at least in a state where it has been added to the PersistenceContext in LOADING state prior to processing Order or its key. This means, though, a pretty drastic change to the internals of Loader. The thing to be aware of on the other side is to not "go too far" in processing Customer, specifically in resolving its associations, since those associations mey still be awaiting processing from the current result set. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2277?page=c... ] Steve Ebersole resolved HHH-2277. --------------------------------- Resolution: Fixed Fix Version/s: (was: cfg-rework) 3.6 -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2277?page=c... ] Steve Ebersole closed HHH-2277. ------------------------------- -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira