it doesn't happen with jdk16
java version "1.7.0.03"
Java(TM) SE Runtime Environment (build 1.7.0.03-jinteg_2012_10_05_02_40-b00)
Java HotSpot(TM) Server VM (build 23.2-b09-jre1.7.0.03-rc1, mixed mode)
db2-97, mysql51, mysql55, mssql2008R2, postgresql83, postgresql84, postgresql91, sybase15, sybase155
, can you take a look at this? Debugging shows EagerKeyManyToOneTest$CustomLoadListener#internalLoadCount going up to 298 before stopping. Not sure why the fix for would act any different for a different JDK.
Funny timing as I am tackling this same question in my LoadPlan work, which is meant as the "pretty serious changes to the concepts of Loader and JoinWalker and OuterJoinableAssociation" referenced in HHH-2277.
I cannot think of anything specific in those changes that would be "JVM dependent". Though we have run into that situation before. I recall us having to fix insidious problems where code would rely on iteration order of non-ordered collections and different JVMs handling that differently.
EagerKeyManyToOneTest revolves around a bidirectional, eager-loaded association which originally caused an infinite loop of loading back and forth from both sides. EagerKeyManyToOneTest checks to make sure the number of loads is less than 10 (an arbitrary value, as far as I know). If it's > 10, the OverflowCondition is thrown. Debugging showed HPUX JDK 7 causing the number of loads to increase to 298 (not sure if that value is significant), but it does not cause an infinite loop.
The original fix is somewhat fragile and assumes JVMs are consistent in their ordering of specific types of lists. The best guess is HPUX JDK 7 may be ordering a list differently. Steve is currently revamping this area upstream ("LoadPlans") and is intermittently hitting the issue again. I think the bottom line is that it's highly unlikely that we'll be able to fix this in ORM 3/EAP 5. The number of loads is high and certainly not ideal, but it is working. Further, HPUX JDK 7 may not be the only JVM where this issue comes up (and later versions may have corrected it).
For now, closing this one. It should be entirely superseded by 's LoadPlan work.