Ouch! Bitten by Manager implementation of doSelectJoin* (incorrect cache configuration)

[Scott Eade <se...@backstagetech.com.au>]

I hadn't noticed this before...

The doSelectJoin* methods include code that identifies if the child 
object just retrieved is also the child object of a previously retrieved 
parent object.  This is a nasty loop the loop function - as each parent 
object is retrieved the child object for the growing list of previously 
retrieved parents must be scanned.

Now I happen to have torque.useManagers set to true but no cache 
configured, so each time a child object is retrieved (via 
ChildManager.getInstance) a query is executed.

In a particular location in my application a user has a larger number of 
related objects that normal (136 rather than a more typical number of 
less than say 10).  When the doSelectJoinChild method is hit the lights 
dim as the 135th Fibonacci number of queries is executed - that's 9180 
queries!

No doubt I can fix this by correctly configuring my cache or by not 
using Managers, but it was certainly an interesting issue to suddenly 
spot in an application that has been ticking along quite nicely for some 
time now.

Note that this particular application is currently stuck back on torque 
3.1.1 - I haven't looked to see if there have been changes that alter 
this implementation.

Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

RE: Ouch! Bitten by Manager implementation of doSelectJoin* (incorrect cache configuration)

[Thomas Fischer <fi...@seitenbau.net>]

As far as I know, nothing has changed in the implementation of the
doSelectJoinXXX since 3.1.1. Would you mind creating a jira issue ?

  Thomas

Scott Eade <se...@backstagetech.com.au> schrieb am 15.08.2006 14:45:34:

> I hadn't noticed this before...
>
> The doSelectJoin* methods include code that identifies if the child
> object just retrieved is also the child object of a previously retrieved
> parent object.  This is a nasty loop the loop function - as each parent
> object is retrieved the child object for the growing list of previously
> retrieved parents must be scanned.
>
> Now I happen to have torque.useManagers set to true but no cache
> configured, so each time a child object is retrieved (via
> ChildManager.getInstance) a query is executed.
>
> In a particular location in my application a user has a larger number of
> related objects that normal (136 rather than a more typical number of
> less than say 10).  When the doSelectJoinChild method is hit the lights
> dim as the 135th Fibonacci number of queries is executed - that's 9180
> queries!
>
> No doubt I can fix this by correctly configuring my cache or by not
> using Managers, but it was certainly an interesting issue to suddenly
> spot in an application that has been ticking along quite nicely for some
> time now.
>
> Note that this particular application is currently stuck back on torque
> 3.1.1 - I haven't looked to see if there have been changes that alter
> this implementation.
>
> Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org