(I see from your next email that you solved the problem - cool!) Tackling some of your questions: 1) "ended up creating" - a better choice of words would be "ended up instantiating".
2) Technically, I mean "recompile the driver with the DEBUG flag on" - this allows any Java debugger to set a breakpoint on the lines in the driver. In particular, in Postgresql, there's an "ExecuteSql" line which has the exact SQL about to execute. I leave a disabled breakpoint on that line in my debugger and if I ever REALLY need to know what's going on, I reenable it. (This trick obviously only works on open-source databases.) 3) Yes, that's the line you want for Log4J logging. Bear in mind that it will usually log select statements but necessarily insert and update statements (which is annoying.) 4) I have to admit that I dislike almost all the public profilers. It's high on the list of "things I would write if I had time." -Peter On Wed, 2003-01-15 at 18:53, Sam Joseph wrote: > 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 > TABLE_NAME = 'EVENT' > [junit] 2003-01-16 08:50:40,993 DEBUG [main] (IDBroker.java:879) - > updateNextId: UPDATE ID_TABLE SET NEXT_ID = 4294967294 WHERE TABLE_NAME > = 'EVENT' > > Hmmm..... > > >3) Check your foreign key relationships to the table. > > > MySQL doesn't actually support foreign key relations in the version I'm > using. > > >4) Run it in a memory profiler and see how many of each object is being > >created. > > > 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. > > CHEERS> SAM > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
