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
>>>>
>

Reply via email to