G
guymills
Guest
Thanks for the reply Stefan. I was thinking of doing a full copy of the temp-tables at appserver startup - to shared temp-tables (!!!) So my thinking was that if we had some code e.g. FIND config WHERE NO-LOCK. it becomes {useCache.i} FIND config WHERE NO-LOCK. where /* useCache.i */ DEFINE SHARED TEMP-TABLE config for config /* using all indexes */. I reckon all I have to do is insert the include file(s) into any procedure that reads (and doesn't update) the tables - the list of which I can get via xref or listings, et voila - I use temp-tables instead of DB tables. And using preprocessors, we could get this to take affect only for dataserver compilations... So the issue is, if we allow "hot" config changes, (i.e. changes that should take affect without restarting the appservers), I need to refresh the data in the cache. An easy but slow way would be to check at every API call against a timestamp value in the DB, and then do a full refresh if that changes. We could have a global timestamp for all config, or a timestamp for each table - or maybe a bit of both - i.e. check the global timestamps and if it's changed, check the table timestamps.... However, by doing any full refresh, it could mean that the first API call on an appserver after a config change could take much longer whilst the temp-tables are rebuilt. Alternatively, I was thinking of doing something like using "audit" data to only refresh those config records that have changed in the "cache". I guess I'll probably start simple, and introduce a better caching model if required. I like your idea of lazily getting the config data, however from what you've indicated, I'm presuming you don't do so "natively" (i.e. using FIND/FOR EACH/QUERY statements against the DB), and instead get it via a helper function or class? - which potentially returns a temp-table, but might get the data from DB? Unfortunately we've got far too many lines of code that accesses the database (hundreds of thousands), that I think it would be very difficult/costly to rewrite all our different statements (most static, some dynamic) to such a construct. But I would be happy to be shown otherwise 
Continue reading...
Continue reading...