On Fri, 01 Jul 2011 09:25:44 -0500, James Horn wrote:
Hi Pete
The caching seems a little scary to me. I assume you don't do it if the
method gets data from a file (or whatever) which could change between
the calls.
Jim
Of course not, if the data could potentially change between calls. Those
types of methods are actions, which don't own the data, and either don't
go in the service program, or sequentially process requests that change
the request keys. Otherwise, yes, I do, especially when I have to
retrieve the data from the database, since those methods tend to be the
most resource intensive.
I cache the returned value and the parameters. When any of the parameters
change, I clear the return value and refresh it. That makes it
unnecessary to retrieve the same data multiple times, and is entirely
transparent to the user of the data. It just makes things run faster.
Typically, the same data is needed by multiple methods in my "expert"
service programs, so it can be requested with impunity whenever it's
needed. Of course, in my environment, the database is relatively static
during the day, and I only cache the most recent request. We have heavy
batch workloads that run at night.
I also implement a clean-up method, that sets a global switch and
executes each method, so that the method itself can clean up its data and
release any resources as appropriate. For good measure, I also tend to
code the requester programs to run in named activation groups that can be
destroyed when the requester ends.
I've had no issues at all with corrupted or stale result data. The
granularity of the cached data is either very fine, or the data itself
can be assumed to be static at processing time.
midrange.com
