I will look into P6Spy, and post the results. Thanks Joe
On Feb 8, 2012, at 11:58 AM, Mike Kienenberger wrote: > I was just trying to restate what other people said. I don't have > anything original to add, unfortunately. > > One thing you can do is to insert the P6Spy database driver into your > app -- this jdbc driver wrapper will provide logging at the jdbc > level, which would let you see what's going on without having to > enable java logging. > > Mysql might also have the ability to log but I'm not really familiar with it. > > On Wed, Feb 8, 2012 at 11:51 AM, Joe Baldwin <[email protected]> wrote: >>> And your next step is to determine how the sort orderings are different (by >>> looking at the log results), determine why a certain sort causes a problem, >> >> OK, but I have absolutely no idea what you are talking about. :) More >> importantly, I am not sure if I have described the test results well enough. >> Let me try again: >> >> Succinct Problem Symptoms (to date) >> 1. The FK error is generated 100% of the time (not intermittently) when I >> tried to add a Product entity. In addition, simply logging into to my app >> (accessing the admin table), trigger the FK error for the Product - which >> was totally illogical since logging into admin does not INSERT a Product >> entity. >> 2. I restarted tomcat and did a recursive "touch" on the JSP dir each time I >> performed the test to presumably clear out the memory and cache. >> 3. The ONLY condition that results in a successful test is to use my >> development tomcat (on my OSX laptop), or set Cayenne logging to DEBUG on >> the production machine. >> >> Confusion: >> 1. I do not know how these symptoms might point to a "sort ordering" issue >> based on the available test results. >> 2. If the problem *NEVER* occurs while logging is set to DEBUG, then how >> would I check the logs as you suggest? >> >> This is why I have suggested that this problem is "insane"; This is sort of >> like a perverted Heisenberg Uncertainty Principle. :) >> >> Question (Based on the "DEBUG Uncertainty Principle"): >> 1. If the FK problem ONLY occurs with DEBUG set to FALSE then I have limited >> visibility into the problem. >> 2. If I set DEBUG to TRUE all the time, then I am concerned I am simply >> hiding a bug. >> 3. Of course, if I set DEBUG to TRUE, then it is "Miller Time" :) >> >> I have the feeling like some configuration file parameter might be >> corrupted. If nobody has any other ideas (give the visibility constraints), >> then I guess I will try to rebuild the project cayenne config files from >> scratch and hack it into submission. :) (Not looking forward to this >> option.) >> >> Thanks >> Joe >> >> >> >> On Feb 8, 2012, at 11:18 AM, Mike Kienenberger wrote: >> >>> Oops. Didn't finish. >>> >>> And your next step is to determine how the sort orderings are >>> different (by looking at the log results), determine why a certain >>> sort causes a problem, and then subclass the sorter to insure it sorts >>> in a consistently-valid manner each time. >>> >>> On Wed, Feb 8, 2012 at 11:15 AM, Mike Kienenberger <[email protected]> >>> wrote: >>>> I think what Michael is saying is that the ashwood sorter isn't >>>> guaranteed to return the same results for the same commit operation on >>>> the next run after the application is restarted. So setting the >>>> logging wasn't what caused the change -- it was restarting the app. >>>> >>>> On Wed, Feb 8, 2012 at 11:02 AM, Joe Baldwin <[email protected]> >>>> wrote: >>>>> Well, if it is not "insane", then what should I do? I mean if the app >>>>> only works correctly when logging is set to DEBUG then I would think that >>>>> indicates a problems. I could run the app with DEBUG on all the time, >>>>> but that would just be covering up what I would assume is a serious >>>>> problem. What should I do next to debug this problem? >>>>> >>>>> More info: >>>>> Each time I update my project jar file, I do a recursive "touch" (which I >>>>> have found forces tomcat to recompile all the jsp's and recognize the new >>>>> jar file). After this, I restart tomcat. There was a problem with the >>>>> webhost's configuration of tomcat caching static variables from the >>>>> previous jar file into jsp static non-variables. I would *presume* this >>>>> would clear out everything, but maybe not. >>>>> >>>>> On Feb 8, 2012, at 9:14 AM, Michael Gentry wrote: >>>>> >>>>>> On Tue, Feb 7, 2012 at 6:03 PM, Joe Baldwin <[email protected]> >>>>>> wrote: >>>>>>> 2. So I found their log4j.properties file and inserted >>>>>>> "log4j.logger.org.apache.cayenne.access.QueryLogger=DEBUG" (I hope >>>>>>> this is what you were thinking of) >>>>>> >>>>>> I actually think you want INFO instead of DEBUG. >>>>>> >>>>>> >>>>>>> 4. Rod Serling moment: when I tried to add the Product entity - for the >>>>>>> first time it did not fail >>>>>>> - detail: it added the Product, there was no Exception >>>>>>> - I verified the Product by listing all of my products >>>>>>> >>>>>>> So, is this 1. Insane, or 2. totally Insane? >>>>>> >>>>>> I've seen AshwoodEntitySorter produce different insert orderings >>>>>> before from different starts. Since you shutdown the application, AES >>>>>> would have to produce a new dependency graph on startup. I'm not >>>>>> saying this is responsible, but it is a possibility. So: 0. Maybe not >>>>>> insane. :-) >>>>>> >>>>>> mrg >>>>> >>
