db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Joseph <gai...@yha.att.ne.jp>
Subject Re: Torque fails on BasePeer.doInsert() [was Re: recursive save]
Date Wed, 15 Jan 2003 23:53:01 GMT
Hi Peter,

Thanks for your mail.

Peter S. Hamlen wrote:

>I've had a similar problem - if I recall correctly, my base object would
>load a related object (eg, an order object loading it's customer object)
>which in turn have ALL the order objects for the customer, each of which
>would then end up loading the customer again.  So essentially, for every
>order, I had a distinct customer object and all the order objects.
>I basically had a poorly defined collection which ended up creating 
... ended up creating ...?

>Admittedly, I didn't see any "TorqueExceptions" being called so my
>experience could be completely worthless.
Ah, but I didn't see any Torque Exceptions either, except when I ran a 
memory profiler (your suggestion 4 below) and could see that a large 
number of TorqueException objects were being created.

>Some debugging hints:
>1)  Put a breakpoint on the executeSQL in the Mysql jdbc driver (I use
>postgresql and use this technique a lot.)  It will show you what objects
>are getting saved.
You mean recompile the jdbc driver with some debug code in it?

>2)  If you can't do 1, check out which SELECT statements are being
>logged (ie, set Torque logging to DEBUG).  This might help seeing what's
>being loaded.  (Again, assumes you run out of memory because objects are
>being created.)
Ah, this sounds like a good idea - I've never known there was any 
logging in Torque.  I guess I'll want something like this:

log4j.category.org.apache.torque = DEBUG, org.apache.torque

Interesting.  Before my JVM memory consumption spirals out of control I 
get this log output:

    [junit] 2003-01-16 08:50:39,451  INFO [main] (IDBroker.java:440) - 
Forced id retrieval - no available list
    [junit] 2003-01-16 08:50:39,641 DEBUG [Finalizer] 
(BasePeer.java:1548) - Elapsed time=220 ms
    [junit] 2003-01-16 08:50:40,602 DEBUG [main] (IDBroker.java:921) - 
updateQuantity: UPDATE ID_TABLE SET QUANTITY = 2147483647 WHERE 
    [junit] 2003-01-16 08:50:40,993 DEBUG [main] (IDBroker.java:879) - 


>3)  Check your foreign key relationships to the table.
MySQL doesn't actually support foreign key relations in the version I'm 

>4)  Run it in a memory profiler and see how many of each object is being
Yes - did that already.  It's where I saw the TorqueExceptions being 
created.  What do you use as a profiler?  I've found it difficult to 
find good open source ones.


View raw message