[ http://issues.apache.org/jira/browse/TORQUE-52?page=all ]
Scott Eade updated TORQUE-52:
-----------------------------
Affects Version/s: (was: 3.2)
(was: 3.2.1)
> 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
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
