db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Eade (JIRA)" <j...@apache.org>
Subject [jira] Closed: (TORQUE-52) Serious performance flaws in Manager data retrieval
Date Fri, 18 Aug 2006 14:16:14 GMT
     [ http://issues.apache.org/jira/browse/TORQUE-52?page=all ]

Scott Eade closed TORQUE-52.

    Fix Version/s: 3.2
       Resolution: Invalid

Excellent news: This issue is no longer present - it was addressed by changes made in 3.2.

In conclusion: Don't use Managers in Torque versions prior to 3.2.

> Serious performance flaws in Manager data retrieval
> ---------------------------------------------------
>                 Key: TORQUE-52
>                 URL: http://issues.apache.org/jira/browse/TORQUE-52
>             Project: Torque
>          Issue Type: Bug
>          Components: Generator
>    Affects Versions: 3.1.1
>         Environment: Any
>            Reporter: Scott Eade
>             Fix For: 3.2
> Where a parent child relationship exists, Torque generates methods such as getParentsJoinChild().
 You use this method because you know you are going to access the Child objects and you want
to eliminate a database hit to retrieve each one.
> Problem 1: If you do not configure caching for the Child object the database will be
hit EVERY time child is retrieved - this includes the check for Parent objects with common
child objects (if a previously retrieved Parent has a Child in common then subsequently retrieved
Parent instances are linked to the previously retrieved Child instances).  The result is that
in an attempt to avoid hitting the database for every child the code actually hammers the
database according to the Fibonacci series.  When you eventually retrieve the Child from the
Parent it goes and hits the database anyway (this is the hit you would have been attempting
to avoid by using getParentsJoinChild() in  the first place).
> Problem 2: If you _have_ configured caching of Child elements then getParentsJoinChild()
is still a total waste of cycles since the eventual retrieval of Child objects does not utilise
any of the additional work that was performed - it just goes and grabs the Child from the
> Conclusion: The getParentsJoinChild() methods that are generated when Managers are enabled
are not only ineffectual when caching is configured, they are down right dangerous when it
is not.
> Solution: The code generated for getChild() when Managers are enabled should be very
similar to the code generated when they are not (i.e. a local copy of the Child object should
be retained by the Parent) - the difference would be that the generated line that retrieves
Child when no local copy exists should use the Manager's getInstance() method to retrieve
the object via the cache rather than ChildPeer.retrieveByPK().
> It is probably not that hard to fix.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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

View raw message