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 Wed, 15 Jan 2003 20:12:02 GMT

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 

Admittedly, I didn't see any "TorqueExceptions" being called so my
experience could be completely worthless.

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.
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.)
3)  Check your foreign key relationships to the table.
4)  Run it in a memory profiler and see how many of each object is being

On Wed, 2003-01-15 at 03:14, Sam Joseph wrote:
> Hi
> Replying to my own post (which I sent to dev and should have sent here - 
> sorry), further investigation suggests that I do not a recursive save 
> problem.  I have now been able to replicate the problem in my test 
> environment and I have determined that the save failure occurs on one 
> database and not on another.  Both are MySQL databases, and the major 
> difference is the size of the table in question.  In the smaller 
> database there are 9000 rows in the table we are trying to insert into. 
>  In the larger database there are 30000 or so.
> The difference could not be more severe.  The 9000 row table receives 
> inserts no problem.  The 30000 row table leads to a OutOfMemory error 
> after BasePeer.doInsert() is called.
> Profiling makes it look like a succession of TorqueExceptions are being 
> called.  I can imagine that the database is throwing an exception, but 
> Torque is getting in a lot of trouble handling it.
> Has anyone else ever had this kind of problem?  
> I guess I'm going to try and check the latest version of Torque out of 
> CVS and see if that helps.
> Sam Joseph wrote:
> > Hi,
> >
> > I seem to be experiencing something that seems like a recursive save. 
> > At least I am getting java.lang.OutOfMemory errors when I am trying to 
> > perform a save() operation. 
> > The odd thing is that it doesn't seem to happen when I run an 
> > independent test, but only when I am running the code from within 
> > Tomcat.  Well, I think in the independent mode the JVM just terminates 
> > itself (it's running within ant).  Whereas in the Tomcat environment, 
> > the JVM doesn't crash out, but the memory consumption spirals up and 
> > up until I get OutOfMemoryErrors.
> >
> > Under these circumstances a recursive bit of code would fit the bill 
> > as culprit, however looking at  my OM classes I see that after the 
> > save() operation in called in my Event object that extends BaseEvent 
> > the following functions are called:
> >
> > [Event] save()
> > [BaseEvent] save(String dbName)
> > [BaseEvent] save(DBConnection dbCon)
> > [BaseEventPeer] doInsert( Criteria criteria, DBConnection dbCon )
> > [BasePeer] doInsert( Criteria criteria, DBConnection dbCon )
> >
> > It is after calling BasePeer.doInsert() that the code hangs - and I 
> > get OutOfMemory errors in a Tomcat environment, and the JVM terminates 
> > in the ant test environment.
> >
> > I haven't placed debug statements with the BasePeer code yet, as that 
> > will require re-compiling the jar etc., but superficially there does 
> > not seem to be any recursion taking place in the OM classes, although 
> > conceivably my bugging operations are not telling the whole story.
> >
> > I have read the emails regarding the recursive saving problem, and 
> > been looking at the latest code in Torque CVS but I can't fathom what 
> > is actually causing the recursive problem being talked about, and 
> > whether it might be the same problem I am experiencing.
> >
> > Could anyone explain to me what the existing recursive save problem 
> > was? Or rather which are the methods that are called recursively and 
> > what triggers them to be called so, a flag or something?
> --
> 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