gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: [Gnumed-update] - add extension method result caching


From: Ian Haywood
Subject: [Gnumed-devel] Re: [Gnumed-update] - add extension method result caching as suggested by Ian [...]
Date: Sat, 18 Dec 2004 16:39:39 +1100
User-agent: Mozilla Thunderbird 0.8 (X11/20041012)

address@hidden wrote:
- I maintain a bad feeling due to cache eviction policy being murky at best
Where's the murk?
If you change something with set_*, the local cache of the matching get_* is junked, the cache is never wrong for local changes.

What you seem to be asking for is distributed cache eviction: a set_* on one machine causes a cache refresh on all machines logged in to the same patient. However this is pointless unless the GUI is updated too, and this is were it gets hairy. (IOW, the issue is no different from when we didn't cache in business layer, because we were still "caching" in the various GUI widget elements)

Of course this is doable: all business objects do
LISTEN <class name>_<pk> on instantiation (via the backend listener)
were this makes sense (so not for elements of the past history, as no-one should be changing that)
and NOTIFY <class name>_<pk> on save_payload () or set_*()

However then GUI code has to register callbacks to know this has happened. If were going to have callbacks, GUI code might as well register with the business layer class via class methods, so they can be called via a display () method after instantiation, too.

Ian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]