db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter S. Hamlen" <pham...@mail.com>
Subject Re: Torque fails on BasePeer.doInsert() [was Re: recursive save]
Date Thu, 16 Jan 2003 22:11:16 GMT
(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

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


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 
>     [junit] 2003-01-16 08:50:40,993 DEBUG [main] (IDBroker.java:879) - 
> = '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.
> --
> To unsubscribe, e-mail:   <mailto:turbine-torque-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-torque-user-help@jakarta.apache.org>

View raw message