cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: Odd error
Date Wed, 08 Feb 2012 16:58:31 GMT
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 <jfbaldwin@earthlink.net> 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 <mkienenb@gmail.com> 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 <jfbaldwin@earthlink.net>
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 <jfbaldwin@earthlink.net>
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
>>>>
>

Mime
View raw message