"Are you integrating it with the OpenACS DB Api (e.g. by using a -memchachetime parameter)?"
No I am not doing that right now. My idea currently is to add another layer between local cache and actual proc execution within util_memoize. This layer queries a set of centralised caching servers for a "key" and updates the local cache.
The advantage is to enable centralized caching in a multiserver environment. This also helps in a ready cache being available for every server in the cluster after it restarts. Aolserver Network variable or a shared memory for multiple servers isnt yet available so I decided to have memcached do the job though ideally the NV feature in Aolserver would be a far cleaner solution.
"Wouldn't it make more sense to write a database driver for memchacheD"
I dont think so. I appreciate the issue we might have if we use db API + memcacheD+bind variables ( specifically db_string ) but the issue is same even if we use db API+util_memoize+bind variables.
for example:
util_memoize [db_string myquery "select name from users where user_id = :user_id"]
will create problems because of lack of unique "key". Having memcacheD or not having it doesnt make a difference here. So the smarter thing is not use such a combination in your application currently. I think the
someproc and someproc _not_cached way of dealing with db_string would suffice for now ( I dont know where else we would have issues apart from db_string ).
The memcacheD parameter option for DB API would too much work for a small issue.
