Re: Torque fails on BasePeer.doInsert() [was Re: recursive save]

[Sam Joseph]

And just to follow up on my previous post. Inspecting my database I found the ID_TABLE looking like this:

+-------------+------------+------------+------------+
| ID_TABLE_ID | TABLE_NAME | NEXT_ID | QUANTITY |
+-------------+------------+------------+------------+
| 101 | KEYWORD | 9508 | 50 |
| 102 | PREDICATE | 180 | 10 |
| 103 | EVENT_TYPE | 160 | 10 |
| 104 | URI | 3990 | 15 |
| 105 | NG_USER | 3110 | 10 |
| 106 | URI_DESC | 3886 | 14 |
| 107 | URI_TRIPLE | 32657 | 136 |
| 108 | EVENT | 2147483647 | 2147483647 |
+-------------+------------+------------+------------+

and looking at the EVENT table I saw I had some very odd numbers in the EVENT_ID columns for like 10 or 15 rows. I deleted them and then set the ID_TABLE back to appropriate values, and now things seem to be okay.

Anybody know what the meaning, or point, of the QUANTITY column is?

CHEERS> SAM

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