| pblais@odstrategies.org 2007-03-08, 6:55 pm |
| If you want to update multi user IMDD tables when the disk copy
changes you'll need a bit more effort. We have a proprietary system
that does this. It's part of a larger custom FileManager class that
inserts some other needed additional layers for other reasons.
Choosing which files to do this for takes a fair amount of testing. It
adds a bit of overhead and the cost is not always worth the effort.
You need to establish a period of time that you'll assume no changes
are significant then at the end of the interval you poll a table with
a date time stamp of the last disk update that you log continuously.
You then have to find the changes and get them back to the local IMDD
copy. It's a fair amount of I/O to do the checking and update so it's
not easy to "pay" the "cost" and come out ahead. If the data is not
mostly static then IMDD may not be worthwhile on a multi user setup.
Ours also runs on top of a SQL Backend and SQL itself cache's a lot of
data. The data we cache locally are customized business rules so they
take a lot of I/O to operate and don't change very much that often,
but there are whole customized sets of data that swap in and out all
day. From that point of view the data stays static locally for long
periods of time relative to a daily sessions for one user. It does
reduce network I/O overall.
As a rule I would say avoid the use of a programmer controlled cache
for non static data over a network without a clear set of metrics to
prove the solution. Concurrency issues can become a worse problem than
slow performance. I don't see a one size fits all approach as
worthwhile. Without total optimization you may not come out ahead. For
us we are just shaving a bit of the delay between the GUI
transactions. It's an application that takes user input for long
periods of time. Data fields are derived one at a time in a dynamic
data entry form. It helps the GUI seem more like a static data entry
form.
On 6 Mar 2007 00:16:15 -0500, "Andre Engelbrecht"
<fivetalents@telkomsa.net> wrote:
>I have used the In-memory driver since it became available, but only
>recently discovered the power of the caching template
>
>In one app I have several IMDD cache files, The contacts file has a
>synchronised cache file that updates changes to the physical file. A second
>cache file is used to populate procedure queues with data from the contacts
>file. This second file is used in many procedures and should be synchronised
>with either the first cache file or the physical file
>
>I am familiar with database triggers, but has someone yet created a class
>(that I could pinch!) to update the IMDD file when the physical file
>changes - the reverse of the IMDD Caching template?
>
>Thanks
>
>
---------------------------------------
Paul Blais - Hayes, Virginia
|