|
Torque
Guides
Howto Guides
Development
|
|
Method Result Cache
|
The above fk relationship will also generate a Bar.getFoos(Criteria). It
would be preferrable that repeated requests to this method returned
cached results as opposed to hitting the db for each call. It could be
possible to add such caching to the generated method, and Criteria
implements an equals() method that would make this possible. But
determining the equality of a Criteria is complex and possibly buggy (this
is the perception of the author of this doc, there are no known bugs).
Invalidating the results has also not been reduced to templated Java code.
So whether to cache these kinds of results is left to the developer
who is using torque.
It is a good practice to write methods within Bar that wrap the
getFoos(Criteria) method. The conversion from application parameters
to a Criteria is then implemented in a more maintainable manner. For
example:
 |
 |
 |
 |
public List getFoos(FooType type, boolean deleted)
{
List result = null;
Criteria crit = new Criteria();
crit.add(FooPeer.TYPE_ID, type.getId());
crit.add(FooPeer.DELETED, deleted);
result = getFoos(crit);
return result;
}
|
 |
 |
 |
 |
In the above code the database will be hit for every call to the method.
BarManager provides some convenience code to add caching to the above
method, so it can be rewritten as:
 |
 |
 |
 |
public List getFoos(FooType type, boolean deleted)
{
List result = null;
Boolean b = (deleted ? Boolean.TRUE : Boolean.FALSE);
Object obj = BarManager.getMethodResult().get(this, "getFoos", type, b);
if ( obj == null )
{
Criteria crit = new Criteria();
crit.add(FooPeer.TYPE_ID, type.getId());
crit.add(FooPeer.DELETED, deleted);
result = getFoos(crit);
BarManager.getMethodResult().put(result, this, "getFoos", type, b);
}
else
{
result = (List)obj;
}
return result;
}
|
 |
 |
 |
 |
The getMethodResult() method returns a MethodResultCache object, which
creates a key from the arguments given in the get method. All the
arguments must be Serializable. The first object should be the business
object on which the method was called. If the object is not Serializable
or the method is static, a String as given by Object.toString() method or
the className might be used. The second argument is the method name.
There are versions of the get method that take up to 3 additional arguments
that will be the arguments to the method, or if they are not Serializable
some Serializable proxy. There is also a get method that takes an
Object[] that can be used for methods that have more than 3 arguments; the
first two objects in the array should be the instance and method name.
The reason for not just having the Object[] format is that keys are pooled
and since most methods will be less than 4 arguments, object creation
related to the cache is minimized. Now the method will return cached
results as long as the results remain in the cache. So there must be some
way to invalidate these results, if the database changes in a way that
is likely to affect the result that should be returned by the method.
|
|
|