[prev in list] [next in list] [prev in thread] [next in thread] 

List:       turbine-torque-dev
Subject:    [jira] Closed: (TORQUE-52) Serious performance flaws in Manager
From:       "Scott Eade (JIRA)" <jira () apache ! org>
Date:       2006-08-18 14:16:14
Message-ID: 26935365.1155910574838.JavaMail.jira () brutus
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]