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] Created: (TORQUE-52) Serious performance flaws in Manager data retrieval
Date Thu, 17 Aug 2006 03:17:17 GMT
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, 3.2, 3.2.1
         Environment: Any
            Reporter: Scott Eade


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

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


Mime
View raw message